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Executive  Summary 


The  United  States  Air  Force  has  contracted  with  TRW  Avionics  and  System 
Division  (ASD)  to  develop  the  processes  and  products  necessary  to  produce 
military  products  in  a  commercial  manufacturing  facility.  This  project  is 
named  Military  Products  from  Commercial  Lines  (MPCL).  A  key  component 
of  MPCL  was  the  development  of  a  world  class  Computer  Integrated 
Manufacturing  (CIM)  system  to  integrate  the  military  design  environment 
with  the  commercial  manufacturing  environment.  Under  MPCL,  a 
Manufacturing  Infrastructure  (MI)  Integrated  Product  Team  (IPT)  was  given 
the  responsibility  for  developing  the  CIM  system.  This  system  was  designed 
to  facilitate  the  production  of  military  electronics  on  commercial  lines.  The 
CIM  incorporates  the  following  features. 

•  Product  Design 

Computer  Aided  Design  (CAD)  tools  were  integrated  with  a  Product  Data 
Management  (PDM)  architecture  system  to  enable  flow  of  design  data 
between  the  design  and  production  centers. 

•  Design-Driven  Production 

An  information  transfer  process  was  developed  that  allows  design  data  to 
drive  the  factory  planning  and  launch  process.  This  system  uses  CAD  files  to 
fully  program  the  factory  systems,  significantly  reducing  launch  time.  All 
information  required  to  build  the  product  is  included  in  the  system. 

•  Product  Quality  Modeling 

A  modeling  tool  was  developed  to  estimate  production  quality  throughout 
the  design  and  production  life  cycle.  This  tool  determines  first  pass  yield, 
production  quality  issues  and  defect  levels  as  delivered  to  the  customer. 

•  Automatic  Product  Change  Over  and  Process  Mistake  Proofing 

This  function  supports  fast  product  change  over  between  military  and 
commercial  products  and  insures  the  change  over  is  complete  and  accurate. 
For  example,  the  system  insures  that  the  correct  production  materials  are 
loaded  into  the  correct  operation  slots.  The  system  also  checks  production 
route,  process  time  limits  and  limits  on  the  number  of  times  a  process  may 
be  repeated  on  a  single  unit. 

•  Factory  Control 

This  function  includes  a  common  set  of  applications  that  provide  factory  level 
command,  control  and  reporting  functions.  “As  built”  data  can  be  obtained 
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from  this  system  along  with  configuration  data.  Tools  to  change  system  and 
factory  setup  are  also  included. 

•  Work  Cell  Control 

The  Work  Cell  Control  function  controls  the  production  floor,  providing 
production  workers  with  quality  and  setup  information  along  with  system 
status  and  process  instructions.  Each  production  work  cell  has  a  computer 
that  provides  the  interface  point  to  the  line.  Bar  code  scanners  and  machine 
control  logic  are  routed  through  these  computers  to  minimize  line  wiring  and 
support. 

•  Centralized  Production  and  Quality  Data  Model 

All  factory  information  is  controlled  and  contained  in  a  single  data  model. 

All  functions  in  the  factory  share  this  data  model  including  the  Work  Cell 
Control  and  Factory  Control. 

•  Highly  Modular  and  Transferable  Information  System. 

The  CIM  system  is  designed  using  rapid  deployment  modular  design  to 
permit  transfer  to  other  sites. 

The  MI  IPT  was  successful  in  purchasing,  developing,  and  deploying  these 
capabilities  at  the  TRW  Marshall  plant.  The  Marshall  Flex  3  line  is  currently 
equipped  with  the  MPCL  CIM  system.  The  MPCL  data  model  is  also  being 
used  for  all  TRW  Marshall  plant  quality  and  performance  data.  The  data 
model  includes  a  mission  critical  failure  analysis  system  that  provides  the 
foundation  for  the  local  RMA  (Returned  Materials)  system.  Remote  control  of 
the  Marshall  Factory  Control  and  Work  Cell  Control  functions  from  San  Diego 
has  been  demonstrated. 

In  addition  to  these  accomplishments  within  TRW,  the  CIM  system  has  been 
adapted  to  Air  Force  depot  requirements  through  the  Warner  Robins  Air 
Logistics  Center  (WR-ALC)  Lean  Sustainment  project.  Another  example  of 
technology  transfer  is  the  Northrop  Grumman  use  of  MPCL  CIM  system 
implementation  strategy  and  lessons  learned  in  their  PDM  implementation 
project. 

1  MPCL  CIM  System _ 

The  efforts  of  the  MI  IPT  resulted  in  a  working  CIM  system.  The 
requirements  for  that  system  are  captured  Manufacturing  Line  Scenarios  and 
Operational  Scenarios  (Section  4  and  5).  The  specifications  for  the  CIM 
system  are  captured  in  the  CIM  System  Design  Description,  User-Based  Data 
Flows  and  Design  Notes  (Sections  6,7  and  8). 
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1.1  Goals  and  Objectives 


In  developing  the  CIM  system,  The  MI  IPT  had  the  following  goals  and 

objectives. 

•  Provide  tools  and  information  systems  to  support  product  design  efforts. 
These  include  analysis  tools,  CAD  tools  and  design  data  storage. 

•  Develop  and  deploy  a  flexible  CIM  System  that  not  only  supports  the 
existing  high  volume  needs,  but  also  provides  for  low  volume  and  high 
mix  scenario  on  the  same  production  line. 

•  Enable  the  seamless  flow  of  data  from  design  to  manufacturing. 

•  Integrate  with  the  automotive  factory  MRP  system. 

•  Test  integration  techniques  with  MPCL  final  assembly  operations  and 
expand  the  MPCL  system  into  other  automotive  business  processes. 

•  Automate  the  Quality  Model. 


1.2  Approach 

The  MI  IPT  adopted  an  approach  that  was  cost  effective  and  easily 
transferrable  to  other  programs.  In  addition,  the  approach  emphasized  non¬ 
interference  with  ongoing  operations  at  the  Marshall  plant.  A  summary  of 
the  approach  follows. 

•  Develop  a  top  down,  modular  system  architecture  that  can  be 
adapted  to  future  growth. 

•  Avoid  tying  the  CIM  System  to  any  particular  vendor’s  tool  or 
application,  thereby  maximizing  transferability  of  technology  to 
support  the  overall  goal  of  MPCL. 

•  Insure  the  CIM  System  integrates  seamlessly  with  the  existing 
systems  at  the  Marshall  plant. 

•  Use  off-the-shelf  packages  where  possible  to  minimize  custom 
design  and  increase  robustness. 

•  Choose  tools  and  products  that  have  low  cost  licensing  structures  to 
avoid  high  recurring  costs. 

•  Provide  a  simple  and  consistent  method  to  interface  and  integrate  to 
a  variety  of  shop  floor  production  equipment. 
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•  Use  the  existing  Marshall  CIM  development  and  maintenance 
environment  so  that  the  new  system  could  be  maintained  without 
much  additional  cost  to  the  Marshall  Plant. 

•  Provide  a  secure  network  access  for  TRW  and  non-TRW  personnel 
distributed  over  many  parts  of  the  country. 

1.3  MI  Accomplishments _ 

Developing  the  MPCL  CIM  system  involved  a  number  of  specific  tasks.  These 
tasks,  listed  below,  are  described  in  detail  in  the  subsections  of  2.3. 

•  Development  of  a  distributed  environment  for  the  design  of  the 
MPCL  products 

•  Using  data  modeling  as  the  backbone  of  CIM  System 

•  Development  of  a  Factory  Control  System 

•  Development  of  a  Work  Cell  Controller 

•  Development  of  a  system  that  seamlessly  integrates  design  and 
manufacturing 

•  CIM  System  Integration,  Test  and  Deployment. 

•  Development  of  Factory  Reports 

•  Demonstrating  the  CIM  system  through  Marshall  commercial 
product  builds  on  the  Flex  3  line 

•  Full  use  of  the  CIM  system  on  MPCL  products 

•  Development  of  a  simple  integration  approach  to  the  Marshall  MRP 
system. 

•  Implementation  of  the  Quality  Model  System  as  part  of  the  MPCL 
factory  system. 

•  Integration  of  the  Router,  ICT,  Pack  and  Bar  Code  print  stations  for 
end  of  line  production. 

•  Demonstrating  remote  production  features 

1.3.1  Distributed  Development  Environment 
Task  Description 

The  development  team  consisted  of  members  from  TRW/ASD  located  in  Ohio, 
California  and  Florida;  TRW  AEN  located  in  Marshall,  IL;  and  software 
vendors  located  in  Ohio  and  Canada.  The  requirement  involved  developing 
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an  environment  in  which  this  dispersed  group  could  effectively  work  in 
unison  to  develop  the  MPCL  CIM  System. 

Methodology 

The  requirements  for  Distributed  Development  Environment  follow. 

•  Provide  configuration  management  and  data  transfer  capabilities  to 
allow  a  simple  and  smooth  transition  from  development,  to 
integration/test  and  finally  to  production. 

•  Ensure  security  so  that  the  various  vendors  could  not  see  each 
other’s  source  code  and  so  that  no  vendor  or  contractor  could  access 
TRW’s  TI-Net  or  Marshall’s  plant  Netware  Production  Backbone 

•  Provide  a  secure  network  access  (in  terms  of  access  to  database, 
services,  etc.)  for  TRW  and  non-TRW  personnel  to  develop  and  test 
the  CIM  System. 

The  approach  was  to  set  up  an  NT  Server  on  the  Marshall  Plant’s  network 
backbone  with  a  Point  to  Point  Protocol  (PPP)  dialup  access  for  TCP/IP  and 
NetBEUI.  No  IPX/NetWare  protocol  was  supported  over  this  PPP  link.  To 
inake  dialup  more  secure,  a  callback  feature  was  set  up  whereby  the 
Marshall  Plant’s  administrator  set  the  phone  number  to  call  back  and 
guarantee  that  access  was  provided  to  “authorized”  and  password  protected 
users  only.  This  access  was  therefore  restricted  to  known  phone  numbers 
established  by  TRW.  To  further  minimize  production  and  development 
separation,  the  TCP/IP  development  network  segment  was  kept  isolated 
through  a  smart  switch  that  would  not  allow  traffic  to  flow  unless  necessary. 
Since  at  any  given  time  more  than  one  person  could  be  dialing,  two  high¬ 
speed  modems  were  setup. 

Results 

Initially,  there  was  some  trouble  getting  some  of  the  remote  users  correctly 
configured  as  most  MIS  personnel  and  users  were  unfamiliar  with  remote- 
dial-up  network  access  procedures.  In  addition,  some  were  using  Windows 
95  and  others  Windows  NT.  This  further  complicated  setting  them  up  at 
their  sites.  However,  once  the  users  were  set  up,  the  access  and  performance 
were  deemed  satisfactory.  There  was  no  noticeable  disruption  of 
development  during  the  entire  development  phase.  Overall,  the  capabilities 
and  productivity  that  resulted  with  this  distributed  setup  was  comparable  to 
those  of  a  development  group  working  in  one  location. 
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1.3.2  Data  Modeling  as  the  Foundation  of  System  Design 
Task  Description 

A  Data  Model  was  used  as  the  foundation  of  the  CIM  system.  The  data  model 
provides  a  plan  for  all  information  required  by  the  system  and  accounts  for 
the  basic  information  required  to  run  the  plant. 

Methodology 

The  approach  adopted  was  to  design  a  complete  CIM  System  Data  Model. 
Alternatives  considered  included  using  Process  and  Data  Flows  to  first  define 
the  design  functionality.  This  data  model  allowed  integration  of  existing  data 
structures  with  those  of  applications  that  were  being  developed. 

The  data  model  addressed  many  types  of  information  needed  to  run  the 
plant  floor.  A  brief  description  of  each  informational  type  follows: 

•  Unit  Tracking 

Production  units  are  tracked  by  serial  number  throughout  the  data 
model.  This  area  of  the  data  model  includes  information  on  each 
serial  number  (when  created,  what  product,  ok  to  build,  etc.)  and 
information  on  the  serial  numbers  history  through  the 
manufacturing  process. 

•  Manufacturing  Site  Configuration 

This  section  of  the  model  tracks  the  operations  and  processes  used 
in  the  manufacture  of  product.  Each  operation  is  located  at  a 
particular  manufacturing  location  and  provides  a  specific  process 
needed  to  complete  a  product. 

•  Product  Configuration 

Each  product  uses  a  specific  Bill  of  Materials  (BOM),  a  manufacturing 
route,  manufacturing  instructions  and  machine  setup.  This  is 
tracked  in  the  model  and  can  be  frozen  to  insure  a  product  is 
produced  with  the  desired  setup. 

•  Machine  Setup  and  History 

The  system  must  track  all  raw  material  as  used  to  provide 
containment  and  historical  information.  This  section  of  the  model 
tracks  the  supplier  lot  numbers  used  to  build  a  given  unit. 

•  Part  and  Part  Family 
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Any  part  used  by  the  system  is  tracked  here.  This  includes  top  level 
assemblies  and  individual  components.  Part  families  allow  parts  to 
be  associated  with  a  given  customer,  line  or  suffix,  and  track 
package  types  for  use  elsewhere  in  the  system. 

•  Users  and  Groups 

System  users  have  rights  to  applications  based  on  group 
membership.  These  tables  provide  this  information  and  also  allow 
records  to  be  tagged  with  information  related  to  who  performed  the 
last  edit  or  update  on  many  applications  in  this  system. 

•  Quality  Model  Tables 

These  tables  support  both  the  projection  of  quality  levels  for  a  given 
product  and  summary  information  on  actual  quality  performance  of 
any  supplier,  process  or  package  type  as  related  to  production 
operations. 

•  Test  or  Verification  Tracking  Tables 

Electronic  assembly  manufacturing  requires  several  testing  steps  to 
insure  electronic  functionality.  These  tables  allow  the  storage  of  test 
plans  and  test  data  for  a  variety  of  situations.  This  supports 
changing  test  plans  through  a  product’s  lifetime  while  still  allowing 
trending,  tracking  and  SPC  activities. 

•  Failure  Analysis  Tables 

Once  defects  are  identified,  repair  technicians  analyze  and  repair 
units  as  part  of  the  production  process.  This  activity  includes 
features  to  track  analyses  performed,  repair  location  and  action  and 
associated  cost  data. 

•  Defect  Codes  and  Menus 

Defect  codes  are  used  to  track  product  defects  that  occur  in  the 
manufacturing  process.  These  tables  allow  a  separate  defect  menu 
based  on  many  factors  including  package  type,  process  and  location 
on  line. 

Results 

Initially,  the  data  model  effort  was  started  using  experienced  vendors.  This 
allowed  a  draft  data  model  to  be  quickly  developed  and  subsequently  used 
for  design  discussions  and  improvements.  The  initial  data  model  was 
heavily  dependent  on  use  of  off-the-shelf  applications.  As  the  design  process 
evolved,  the  data  model  was  refined  to  balance  this  with  the  needs  of  the 
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MPCL  program  and  the  Marshall  Plant’s  needs.  As  a  result,  considerably 
more  time  was  spent  on  this  activity.  However,  in  the  end,  this  approach 
minimized  CIM  system  design  revisions  during  the  development  and  testing 
phases  of  the  project.  This  model  became  the  foundation  for  all  systems 
planned  for  the  Marshall  plant  floor.  The  model  is  shown  in  Figure  1. 3.2-1. 

1.3.3  Factory  Control  System  (FCS)  Development 

Task  Description 

Once  the  design  phase  started,  off-the-shelf  packages  were  evaluated  to 
determine  their  potential  use  in  the  FCS.  The  objective  was  to  use  available 
off-the-shelf  technology  to  the  greatest  extent  possible  without  sacrificing 
functionality  in  meeting  the  MPCL  requirements. 

Methodology 

The  needs  identified  for  the  FCS  Development  effort  included; 

•  Provide  opportunity  to  integrate  off  the  shelf  packages  where 
possible  to  minimize  custom  development. 

•  Support  interfacing  to  existing  MRP  systems,  and  allow  for  the  MRP 
System  to  be  changed  in  the  future. 

•  Provide  a  low  cost  licensing  structure  for  future  systems  within 
TRW. 

The  selected  approach  was  hybrid  in  nature,  combining  one  off-the-shelf 
package  and  with  a  vendor-specific  factory  control  and  configuration  system. 
The  vendor  worked  with  the  existing  TRW  design  team  and  developed  a 
custom  factory  control  system.  The  factory  control  system  was  designed  to 
meet  the  following  needs: 

•  User  Manager 

The  factory  control  system  user  manager  is  required  to  add  new 
users  and  to  select  system  rights  based  on  group  membership.  This 
includes  the  ability  to  track  skills  to  insure  an  operation  is  only 
operated  by  a  trained  individual. 
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Figure  1.3.2-1.  The  MPCL  Data  Model 


•  Defect  Manager 

The  defect  manager  allows  the  configuration  of  defect  codes.  This 
configuration  allows  a  custom  defect  menu  based  on  the  actual 
production  situation.  Such  an  approach  was  selected  to  minimize  the 
amount  of  codes  that  an  operator  has  to  select,  reducing  data  entry 
time  and  reducing  the  occurrence  of  wrong  code  entry. 

•  Site  Manager 
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This  tool  allows  engineering  setup  of  the  factory  operations, 
processes  and  manufacturing  locations.  An  operation  can  not  appear 
on  the  production  route  until  it  is  added  using  this  tool. 

•  Route  Manager 

The  route  manager  sets  the  production  route  for  a  given  product. 
This  route  can  limit  the  number  of  repetitions  of  a  process  and  the 
time  allowed  between  processes.  For  example,  a  board  must  be  re¬ 
flowed  within  four  hours  of  solder  paste  application. 

•  Setup  Manager 

This  tool  allows  a  user  to  edit  the  part-to-slot  relationship  on  every 
production  machine.  This  relationship  is  initially  set  by  the  design- 
to-production  system  and  only  occasionally  requires  edit  or  change. 

•  Part  Manager 

The  part  manager  allows  the  addition,  edit  or  deletion  of  a  part  or 
assembly.  Part  families  are  also  edited  with  this  tool. 

•  Configuration  Manager 

A  configuration  defines  the  product,  BOM,  route,  setup  and 
instructions  used  for  a  particular  production  lot.  This  tool  allows  the 
user  to  select  the  correct  setup  for  a  given  product  and  it  allows  the 
product  to  be  frozen  or  locked  into  place. 

•  BOM  Manager 

This  tool  allows  the  creation,  edit  or  deletion  of  a  Bill  of  Materials 
(BOM).  Since  new  BOM’s  are  created  by  the  design-to-production 
system,  this  tool  is  typically  used  for  editing  purposes  only. 

•  Instruction  Manager 

Each  operation  has  process  instructions  or  programs  to  perform  the 
given  operation  successfully.  This  tool  allows  the  user  to  determine 
what  instructions  or  machine  programs  are  required  to  produce  the 
product.  This  also  allows  check  boxes  to  be  displayed  and  checked 
off  as  part  of  the  setup  or  change  over  process. 

•  Schedule  Manager 

The  schedule  manager  determines  what  can  be  built  by  the  line.  It 
uses  a  continues  flow  model  that  can  accept  varying  lot  sizes  to 
support  either  high  volume  or  low  volume  product  mixes. 
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Results 


Like  any  custom  development  effort,  there  were  some  hurdles  to  overcome 
such  as  making  trade-offs  between  flexibility  and  robustness  or  between 
new  tools  offering  added  performance  and  proven  tools.  These  tradeoffs 
took  a  bit  longer  than  expected  and  hence  there  were  some  delays  in  getting 
all  the  development  done  within  the  original  schedule.  However,  this  minor 
delay  in  developing  the  PCS  had  no  impact  on  the  overall  schedule  for  MPCL. 

1.3.4  Work  Cell  Controller  (WCC)  Development 

Task  Description 

The  objective  was  to  migrate  as  much  of  the  Marshall  CIM  technology  and 
investment  into  the  MPCL  CIM  System  without  sacrificing  functionality  in 
meeting  the  MPCL  requirements.  Similar  to  the  PCS  development,  off-the- 
shelf  packages  that  would  address  the  WCC  requirements  were  evaluated. 


Methodology 

The  needs  identified  for  the  WCC  Development  effort  included: 

•  Support  the  Marshall  Plant’s  goal  to  migrate  as  much  of  the 
developed  CIM  technology  and  investment  into  the  MPCL  CIM 
System. 

•  Provide  a  simple  and  consistent  method  to  interface  with  a  variety 
of  shop  floor  production  equipment  to  support  Program 
Upload/Download. 

•  Synchronize  with  the  existing  CIM  development  and  maintenance 
environment  so  that  this  new  WCC  system  could  be  maintained 
without  additional  cost  to  the  Plant. 

•  Provide  a  low  cost  licensing  structure  for  future  systems  within 
TRW. 

•  Allow  a  sophisticated  and  simple  method  to  input  defect  data  at  any 
station.  This  method  employs  the  CAD  files  to  draw  a  picture  of  the 
product  allowing  a  touch  screen  entry  of  the  exact  defect  on  the 
exact  part.  The  system  tags  this  information  to  the  correct  serial 
number  and  allows  a  “repair  it  later”  functionality. 
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•  Control  the  production  line  to  insure  the  line  would  not  produce 
product  unless  all  start-up  conditions  were  satisfied  (correct 
material  in  correct  slots,  valid  route,  valid  BOM,  valid  timing,  etc.). 

•  Allow  the  display  of  process  instructions  and  checklists  at  each 
operation  to  support  a  paperless  system. 

•  Support  data  input  from  users  in  three  different  ways  to 
accommodate  different  levels  of  computer  skill  and  manual 
dexterity.  The  three  methods  included  keyboard,  mouse  and  touch 
screen. 

•  Provide  an  advance  notification  of  changeover  to  downstream 
stations  to  speed  changeover. 

The  approach  was  to  use  the  same  base  tools  and  Graphical  User  Interface 
(GUI)  technology  used  at  Marshall  on  other  lines  to  develop  the  WCC.  This 
included  using  Visual  Basic  4.0  as  the  development  language  of  choice  and 
using  the  existing  Real  Time  Feedback  System’s  GUI  as  the  basis  for  operator 
interaction.  In  addition,  to  support  different  databases  and  allow  the  WCC 
development  to  integrate  with  existing  databases  at  Marshall,  a  compatibility 
layer  using  Open  DataBase  Connectivity  (ODBC)  methodology  was  used.  This 
allows  the  WCC  to  be  deployed  on  other  databases  with  minimum  changes  to 
the  WCC  source  code. 

Results 

Overall  the  development  effort  for  the  WCC  required  a  joint  effort  among 
TRW  AEN,  TRW  ASD,  and  two  separate  vendors.  Even  with  this  distributed 
development,  the  effort  progressed  without  setbacks.  As  issues  came  up, 
they  were  resolved.  Each  group  was  able  to  get  “stub”  (black  box)  code 
developed  that  interfaced  with  each  other.  The  resulting  code  has  been 
implemented  on  at  least  13  computers  covering  about  20  operations  used  for 
the  MPCL  product  builds.  Product  work  flows  in  both  Marshall  and  San  Diego 
are  controlled  by  the  WCC.  QS-9000  requirements  are  also  supported  as 
required  to  maintain  certification. 

1.3.5  Design-to-Manufacturing  System 

Task  Description 

The  objective  was  to  take  the  various  design  outputs  and  provide  a  set  of 
interface  utilities  and  tools  that  would  simply  and  efficiently  extract  the 
manufacturing  data  from  the  design  database  and  populate  the  CIM 
database.  Many  of  the  Factory  Control  System  (FCS)  applications  are  used  to 
support  this  system.  This  system  assumes  a  minimum  of  CIM  support  by 
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providing  engineering  applications  for  system  setup  purposes,  negating  the 
need  for  setup  by  Marshall  CIM  engineers. 

Methodology 

The  needs  identified  for  the  WCC  Development  effort  included: 

•  Provide  a  standard  method  to  define  interfaces  to  a  variety  of  CAD 
System  outputs. 

•  Provide  tools  and  utilities  for  a  number  of  data  elements,  including 
Component  Placement  Data,  Solder  Mask  Bitmaps,  Engineering  Bill  of 
Materials  and  Selection  of  Reference  Designators. 

A  detailed  methodology  and  flow  chart  was  created  to  show  how  the 
“approved”  design  data  and  supporting  files  would  be  transferred  from  the 
design  center  to  the  manufacturing  center.  The  methodology  included  what 
processes  performed  by  whom  would  result  in  the  extraction  of  the 
manufacturing  data.  To  assure  compatibility  with  Marshal,  Visual  Basic  4.0 
was  the  development  language  of  choice.  The  existing  Marshall  design-to- 
manufacturing  utilities  for  the  Caterpillar  diesel  engine  control  products  were 
the  basis  for  this  development.  Different  CAD  outputs  were  put  into  a 
“universal”  common  format  to  be  used  to  extract  the  data  to  the  CIM 
database.  Several  vendor  packages  were  evaluated  to  determine  if  they 
could  be  applied  or  used.  The  conclusion  was  that  vendor  tools  would  not 
provide  all  the  utilities  and  would  require  more  work  to  customize  and 
integrate  than  evolving  the  existing  Marshall  tools  to  meet  MPCL  CIM  needs. 

Results 

The  use  of  the  design-to-manufacturing  system  is  expected  to  decrease  the 
time  required  for  design  to  manufacturing  from  a  typical  200  hours  to  less 
than  20. 

1.3.6  Factory  Reports 
Task  Description 

The  MPCL  CIM  system  provides  support  for  a  variety  of  reporting  needs  of 
the  factory.  Factory  reports  support  engineers,  who  configure  and  monitor 
the  CIM  System,  supervisors  who  manage  the  production  line  and  operators 
who  operate  the  equipment. 

Methodology 

The  needs  identified  for  the  Factory  Reports  development  effort  included: 

•  Provide  the  capability  to  easily  create  and  distribute  new  reports  in 
textual  and  graphical  formats  with  “drill  down”  capability. 
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•  Integrate  off-the-shelf  reporting  packages  where  possible  to 
minimize  custom  development. 

•  Support  not  only  the  real  time  needs  of  the  line  for  immediate 
status,  but  also  the  need  for  configuration,  supervisory  and 
management  reports  that  cover  more  than  one  shift’s  worth  of  data. 

The  methodology  used  was  varied.  For  the  WCC,  where  the  reports  required 
are  “immediate”  and  well  defined,  a  graphical  reporting  engine  was 
integrated  within  the  WCC.  The  reports  here  included  basic  production  and 
defect  data  in  graphical  format  with  Pareto  charts  to  identify  cause.  On  the 
PCS,  where  the  needs  for  reporting  will  constantly  evolve  and  change,  an 
Oracle  report-generation  tool  was  selected.  Using  this  tool,  new  reports  can 
be  developed  and  quickly  deployed.  A  number  of  reports  have  been 
developed  that  can  simply  be  accessed  from  the  FCS  Menu.  This  tool  also 
provides  the  capability  to  have  reports  shown  on  the  screen  or  printed  to 
any  system  printer. 

Results 

Defining  and  developing  reports  is  generally  difficult  since  there  is  a 
continuous  need  for  new  reports  or  enhancement  of  existing  reports.  WCC 
reports  that  were  well  defined  and  would  rarely  change  were  tightly 
integrated  with  WCC.  However,  in  the  case  of  the  FCS  area,  flexibility  is 
needed,  and  it  is  more  important  to  have  a  tool  that  allows  quick  creation 
and  deployment  of  new  reports. 

1.3.7  System  Integration  and  Deployment 

Task  Description 

The  objective  was  to  integrate  all  the  different  applications  that  make  up  the 
MPCL  CIM. 

Methodology 

The  needs  identified  for  the  system  integration  and  deployment  effort 
included: 

•  Perform  as  much  of  the  system  integration  effort  as  possible  prior  to 
the  Design  Validation  (DV)  and  Process  Validation  (PV)  builds. 

•  Use  MPCL  boards  during  DV  and  PV  to  perform  system  integration. 

•  Deploy  on  Production  Flex  Line  3  to  support  board  production  for 
MPCL  only. 

•  Start  with  a  “new”  database  and  “newly”  deployed  WCC  stations  to 
identify  any  issues  with  a  full-up  production  roll-in. 
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The  Preliminary  System  Integration  and  Test  effort  was  started  in  the 
development  environment.  This  environment  provided  basic  testing  and 
system  integration  of  the  CIM  System.  Initial  bugs  and  issues  were  resolved 
prior  to  any  DV  or  PV  builds.  At  the  time  of  the  DV  build,  system  integration 
testing  was  performed  to  determine  how  the  newly  integrated  system 
improved  monitoring  and  management  of  the  production  process. 

Results 

The  results  in  this  area  were  mixed.  One  of  the  two  major  problems  was  that 
the  time  allotted  to  set  up  and  test  the  WCC  stations  was  very  limited.  The 
second  problem  was  that  not  enough  time  or  boards  were  allotted  for  the  MI 
Team  to  truly  integrate  the  system.  As  a  result,  a  lot  of  work  still  remains  to 
be  done  to  “proof’  the  entire  system  from  start  to  finish. 

1.3.8  Demonstrating  the  CIM  System  through  Commercial  Product  Builds 
Task  Description 

A  commercial  product  was  manufactured  using  the  MPCL  CIM  system.  The 
chosen  commercial  product  was  normally  produced  on  line  3,  but  without  the 
benefit  of  a  CIM  system.  This  task  was  chosen  to  help  meet  the  goals  of 
proving  final  deployment  and  the  expansion  of  the  MPCL  system  into  the 
automotive  business.  The  build  of  the  commercial  product  would  use  the  full 
system,  including  automated  system  setup  (design  to  production  system), 
release  into  production  with  the  “PCS”  applications  and  production  line 
control  with  the  “WCC”  application. 

Methodology 

The  commercial  product  used  the  same  CAD  system  as  MPCL  products 
(Mentor).  This  allowed  a  direct  test  of  the  entire  system,  from  design 
through  build.  The  builds  required  the  CIM  system  to  incorporate  existing 
plant  processes  derived  from  QS-9000  standards.  They  also  required  a  level 
of  training  and  involvement  by  the  document  control  department  to  insure 
configuration  standards  were  met  and  that  change  control  was  enforced. 

Results 

The  commercial  design  center  provided  the  product  design  files  in  a  standard 
text  format  (neutral  files).  Some  minor  component  updates  had  been  made 
to  the  product  since  the  last  computer  design  effort.  These  changes  were 
noted  and  were  input  once  the  automated  phase  of  product  setup  was 
complete.  The  utilities  in  the  CIM  factory  control  system  were  able  to  read 
the  design  files  without  major  issues.  Minor  issues  included  the  lack  of  “line 
feed”  characters  in  the  neutral  file  requiring  a  simple  adjustment  in  a  word 
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processor.  The  outline  of  a  few  components  as  rendered  in  the  on-screen 
graphics  required  small  corrections.  The  system  BOM,  on-screen  graphics 
and  associated  files  were  correctly  translated  from  the  neutral  file  into  the 
Oracle  database. 

Machine  setup  information  that  define  the  part  numbers  to  be  loaded  into 
each  machine  slot  were  loaded  from  files  provided  by  the  machine 
programming  engineers.  These  were  automatically  loaded  without  issue. 

Once  the  neutral  file  was  loaded,  the  route  defining  the  operations  that  were 
required  to  build  the  product  were  entered  into  the  system.  Document 
control  associates  then  loaded  process  instructions  into  the  system  and 
assisted  with  a  100%  check  of  the  BOM,  setup  and  instructions  prior  to 
release.  Issues  noted  included  some  errors  introduced  by  manual  entries  of 
changes  that  were  not  reflected  in  the  design  files. 

Scanner  locations  had  to  be  modified  on  the  MPCL  boards  to  support  the  bar 
code  location  required  on  the  selected  commercial  product. 

The  build  was  then  scheduled  in  the  system  and  material  was  loaded  on  the 
machines.  Minor  issues  were  encountered  while  scanning  in  the  raw  material 
due  to  slot  number  errors  in  the  data.  The  system  did  not  allow  the  line  to 
run  until  these  issues  were  resolved,  preventing  the  build  of  non-conforming 
product. 

The  product  flowed  down  the  line  smoothly.  The  system  insured  the  correct 
route  was  utilized  and  no  further  issues  were  encountered  on  the  first 
several  operations.  A  hardware  issue  was  encountered  between  operations 
123  and  125.  These  two  assembly  machines  were  combined  into  one 
operation  in  the  MPCL  CIM  system  on  earlier  builds.  The  flow  of  the  product 
between  these  two  operations  allowed  some  boards  to  pass  prior  to  a  check 
of  the  database  to  insure  configurations  and  routes  were  correct  on  that 
particular  serial  number.  The  CIM  system  used  a  clever  interface  to  control 
the  conveyors  without  requiring  modification  of  the  PLC  control  code.  It  was 
determined  that  this  approach  only  worked  when  there  was  a  conveyor 
between  two  assembly  operations.  Operations  123  and  125  were  connected 
directly  and  therefore  will  require  a  different  flow  control  method  (such  as 
hard  pneumatic  stops). 

Overall  the  build  results  were  excellent  and  the  CIM  system  performed  as 
intended. 


16 


1.3.9  Full  Use  of  the  CIM  System  on  MPCL  Products. 

Task  Description 

Use  of  the  MPCL  CIM  system  for  MPCL  production  is  an  obvious  project  task. 
Several  PV  (production  validation)  were  manufactured  during  Phase  III. 

This  included  both  PV  and  production  builds  of  PNP  and  FEC  modules  (A  and 
B-sides). 

Methodology 

Full  system  setup  and  deployment  was  implemented  for  each  build.  The  two 
MPCL  products  (FEC  and  PNP)  were  divided  into  6  assemblies  within  the  CIM 
and  MRP  systems.  This  configuration  supported  the  assembly  process.  For 
example,  one  PNP  unit  is  produced  as  a  PNP  side  A,  PNP  side  B  and  PNP 
assembly  (combination  of  side  A  and  side  B). 

Earlier  builds  completed  during  Phase  II  focused  on  the  central  functions  of 
the  system.  These  included  the  basic  Work  Cell  Controller  (WCC)  functions, 
board  and  material  scanning,  conveyor  control  and  defect  entry.  These 
central  functions  worked  without  fail  during  Phase  III  production.  Phase  III 
demonstrations  focused  on  insuring  the  system  would  perform  during  actual 
builds.  System  reports  were  fully  tested  with  actual  data  allowing  a  more 
complete  systems  check. 

Results 

Minor  issues  with  late  changes  were  detected  by  the  system  during  setup 
and  were  quickly  resolved.  These  changes  consisted  of  minor  slot  changes 
for  material  and  a  couple  of  late  component  changes.  The  line  computer 
systems  worked  as  designed  during  the  build.  A  number  of  minor  issues 
with  the  Factory  Reports  were  corrected  as  they  were  identified.  One  issue 
was  the  need  to  clear  the  slot  location  data  tables  after  a  material  lot  change. 

1.3.10  Development  of  a  Simple  Integration  Approach  to  the  Marshall  MRP  System. 

Task  Description 

The  task  of  integration  with  the  MRP  system  was  planned  for  Phase  III. 
Marshall  had  a  planned  change  of  its  MRP  system  due  to  Y2K  issues  and 
other  considerations.  This  change  was  planned  to  be  complete  during  Phase 
III  activities,  but  was  delayed.  This  forced  the  MPCL  MI  team  to  create  an 
interface  for  MRP  systems  that  was  generic  and  easily  adaptable  to  any 
future  system  that  would  be  considered.  This  interface  was  a  compromise 
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since  the  preferred  integration  approach  would  have  involved  sharing 
existing  tables  within  each  system. 

The  import  of  data  into  the  MPCL  CIM  system  was  identified  as  an  area  of 
concern.  The  team  decided  on  a  flat  file  transfer  technique  with  the  intent  to 
improve  this  system  once  the  new  MRP  system  was  deployed  and  stable. 

The  task  then  became  the  development  of  generic  tools  for  such  transfers. 

Methodology 

The  adopted  approach  allowed  the  input  of  data  to  the  CIM  data  model  from 
external,  comma  delimited  files.  Since  the  MRP  system  is  known,  the 
application  would  be  generic  and  would  include  a  few  standard  input 
formats.  Future  inputs  could  then  be  added  with  minimal  effort  requiring 
only  a  SQL  query  and  configuration  file  changes  to  add  new  imports. 

A  generic  data  import  tool  was  designed  that  could  be  used  to  transfer 
information  into  any  part  of  the  data  model.  This  tool  was  designed  using 
the  modular  functions  that  support  the  WCC  and  factory  level  applications. 

Data  output  to  the  MRP  system  was  added  via  the  reporting  functions.  The 
current  reporting  functions  provide  output  in  both  report  format  and  text  file 
format.  The  text  file  format  is  intended  to  support  the  required  flat  file 
integration. 

Once  the  MRP  system  is  in  place  and  considered  very  stable,  these  interfaces 
should  be  eliminated.  Direct  access  to  tables  would  permit  seamless 
integration  assuming  the  MRP  system  is  master  for  configuration  data  and 
the  CIM  system  is  master  for  the  “as  builf’and  WIP  information. 

Results 

The  data  import  application  was  developed  with  a  standard  input  of  the  BOM. 
The  BOM  was  selected  due  to  it’s  central  nature  and  because  it  impacts  a 
number  of  tables  in  the  data  model  The  interface  for  the  data  import  tool  is 
shown  in  Figure  1.3.10-1. 


Figure  1.3.10-1.  Data  Import  Tool  Interface. 


Selecting  an  item  on  the  tree  and  then  pressing  the  OK  button  displays 
another  dialog  box  that  lists  the  information  needed  to  complete  the  import. 
This  form  is  shown  in  Figure  1.3.10-2. 
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Figure  1.3.10-2.  Data  Import  Tool  Dialog  Box 


This  format  is  intended  to  be  setup  by  a  CIM  engineer,  who  would  create  a 
new  import  type  and  then  any  office  user  with  sufficient  rights  could  use  it. 
Other  potential  areas  for  input  from  the  MRP  system  include  the  Route, 
component  assembly  by  operation  and  scheduling  information. 

1.3.11  Implementation  of  the  Quality  Model  System  as  Part  of  the  MPCL  Factory  System. 

Task  Description 

The  Quality  Model  (QM)  is  a  set  of  methodologies  and  procedures  that 
enables  the  quality  of  a  product  to  be  defined  in  terms  of  PPM  (part  per 
million)  failures.  This  methodology  consists  of  identifying  the  key 
contributors  to  product  quality  problems  and  verifying  the  elimination  of 
these  contributors.  The  Quality  Model  runs  as  a  routine  under  the  CIM 
system,  using  data  collected  by  the  CIM  system. 

Methodology 

The  approach  was  to  exercise  the  model  manually  and  then  use  the 
experience  to  automate  the  process.  Five  models  were  completed  manually 
on  FEC  A,  FEC  B,  PNP  A,  PNP  B  for  MPCL  and  two  commercial  products.  The 
manual  effort  refined  the  approach  and  provided  feedback  on  techniques  for 
automation.  While  much  of  this  effort  was  semi-manual  (excel  spreadsheets) 
the  base  information  was  maintained  in  a  manner  that  closely  matched  the 
planned  data  model. 

The  experience  from  these  manual  efforts  was  then  applied  to  the 
development  of  the  automated  system.  The  data  model  was  refined  and  a 
complete  specification  was  generated  prior  to  coding.  The  specification 
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defined  all  user  interfaces  and  data  base  tables.  The  resulting  automated 
system  used  data  modeling  techniques  and  user  interfaces  to  minimize  the 
amount  of  data  input. 

The  main  function  of  the  Quality  Model  is  to  allow  new  designs  to  be  rated  for  their  quality 
potential.  To  achieve  this,  a  number  of  the  following  functional  elements  have  to  be  made  available 
(Figure  1.3.11-1). 

•  QM  shall  maintain  parts-per-million  (PPM)  values  for  processes  and  supplier  parts  and  history 
for  PPM  changes. 

•  QM  shall  maintain  process  verification  effectiveness  and  history  for  effectiveness  changes. 

•  QM  shall  compute  and  display  the  results  of  the  product  PPM  based  on  PPM  inputs  of 
supplier  parts,  processes,  and  verification  effectiveness. 

•  QM  shall  provide  a  set  of  reports  to  provide  the  results  of  the  quality  model  PPM  for  the 
product. 


QiatityData 
Configuration 
Maintenance 
User  Quality  Eng. 
«RS-S.3.1» 
«DN-11» 

*  Allov  Configiration  of 
process  PPM  and 
supplier  PPM  for  process. 

*  Keep  track  of  history  of 
modfication. 

Allow  review  of  history 


Quality  Mnriel  (QM)  Ptataflrm/ 


Verification  Effectiveness 
Maintenance 
User  QualiV  Eng. 
«RS-5.3.1» 
«ON-11» 

*  Maintain  verification 
effectiveness  by  process 
and  by  parts. 

*  Keep  track  of  history  of 
modification. 

*  Allcw  review  of  history. 


Product  Structure 
Maintenance 
User  Planner 
«R«.1.3» 
«DIW» 

‘  Create  Mfg.  BOM 


Create /Maintain  Route 
User  Process  Engr 
«  RS-5.4.2» 
«DN-10k> 

•  Create  New  route  from 
scratd)  or  by  copying. 


Quality  Model  Analysis 
User:  Qialify  Eng. 
«  RS-5.3.1» 

*  /Vnalyze/Evaluate 
quality  model  fa  product 
effectiveness. 

*  Di^Iay  Quality  Model 
results. 


Qiality  Model 

Computation 

«RS.5.3.1» 

•  Compute  Quality  Model 

PPM  fa  product 

Quality  Model  Results 
UseR  Quality  Eng.  /  Plamer 
«IS-5l3.1»,  «DN'13» 

*  Computation  results  of  quality  model  of 
the  product. 


Figure  1.3.11-1.  Quality  Model  Dataflow 
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Results 


In  general,  a  user  will  start  the  application  as  discussed  above  and  get  into 
the  QM  or  FCS  Screens.  This  will  be  modeled  similar  to  the  FCS  screens.  The 
time  will  be  synchronized  with  the  database  time  using  the  Compatibility 
Layer  functions.  Once  the  QM  Opening  Screen  comes  up,  the  user  will  be 
guided  to  all  other  screens  necessary  to  create,  modify  or  view  either  a 
Quality  Model  or  a  Default  Prediction  Set.  The  first  screen  is  shown  below. 


Figure  1.3.11-2.  Quality  Model  Top  Level  Screen 


This  screen  allows  the  user  to  manage  all  quality  models  in  the  system.  Provisions  for  editing  a 
selected  model  are  included.  One  must  view  a  model  in  order  to  view  reports  since  the  reporting 
functions  are  all  model-specific  in  nature.  New  models  are  also  created  from  this  screen.  A  new 
model  can  be  either  completely  new  or  a  copy  of  an  existing  model.  This  allows  the  easy  analysis  of 
several  “what  if’  scenarios  or  design  approaches.  Data  entered  into  the  system  is  automatically 
used  as  default  data  on  other  products  that  use  the  same  line  and  operation.  This  default  data  can  be 
viewed  and  edited  independent  of  an  individual  model  if  needed. 


Once  a  model  is  selected  for  editing,  a  screen  shows  the  model  status  and  predictions  as  they  are 
entered.  The  main  Quality  Model  edit  and  view  screen  is  shown  in  Figure  1.3.1 1-3. 


22 


Figure  1.3.11-3.  QM  Edit  and  View  Screen 


The  model  details  are  shown  here  by  reference  designator.  Green  bars  show  how  much  of  the 
required  supplier  and  process  data  is  entered.  The  total  PPM  rates  at  any  point  in  the  modeling 
exercize  are  calculated  and  displayed  on  this  screen  both  with  and  without  verification  applied. 
Other  tabs  are  selectable  to  edit  process,  supplier  and  verification  data.  The  supplier  and  process 
PPM  screens  are  simular  to  the  above  screen.  The  verification  screens  are  slightly  different  as 
shown  in  the  Figure  1.3.11-4. 


Figure  1.3.11-4.  QM  Verification  Screen 

Verification  information  can  be  entered  on  any  process  on  the  production  route.  A  set  of  standard 
verification  types  are  maintained  by  the  system  requiring  the  user  to  simply  tag  the  verification 
type  to  the  operation  and  reference  designator  involved. 


Once  a  model  has  been  completed,  graphical  reports  are  available  to  assist  in  managing  the  quality  of 
the  product  and  processes  being  modeled.  Excel  spread  sheets  of  the  entire  data  set  can  also  be 
generated  by  the  system  for  off-line  analysis.  An  example  of  the  graphical  output  of  the  quality 
model  in  shown  in  Figure  1 .3.1 1-5. 


PNP  A  copy  test,  only  defaults  By 
Operation,  Without  Verification 


Figure  1.3.11-5.  QM  Graphical  Output 


An  implementation  that  maximizes  the  value  of  this  tool  should  involve  a  gradual  rollout  and 
accuracy  check.  The  accuracy  of  the  tool  is  directly  related  to  the  accuracy  of  the  input  factors 
involved.  All  models  must  grow  and  improve  over  time  to  remain  useful.  This  evolution  involves 
comparing  model  data  with  actual  results  and  the  adjustment  of  input  factors  based  on  actual  data. 

Starting  with  modeling  all  products  on  one  line  and  then  proceeding  to  the  next  line  is  recommended. 
This  implementation  maximizes  the  benefit  of  the  automated  system  since  the  first  product  on  any 
given  line  is  the  most  work.  Once  the  first  product  is  modeled,  other  products  can  be  modeled 
quickly  on  the  same  line  since  they  use  many  of  the  same  processes  and  thus  use  the  same  default 
data. 

The  tool  allows  data  input  for  a  given  product  and  line  or  data  input  for  global  values.  The 
recommended  focus  would  be  on  a  product  by  product  basis  rather  than  on  entering  defaults. 
Verification  effectiveness  data  can  only  be  entered  on  a  product  by  product  basis. 

The  most  pressing  issue  in  terms  of  deploying  this  system  is  the  input  of 
BOM  data.  The  MPCL  system  is  designed  to  accept  BOM  data  directly  from 
the  CAD  files.  Different  file  formats  could  cause  a  data  transfer  problem.  The 
data  import  tool  designed  for  MRP  integration  helps  resolve  this  issue. 
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1.3.12  Integration  of  the  Router,  ICT,  Pack  and  Bar  Code  Print  Stations  for  End-of-Line 
(EOL)  Activities 

Task  Description 

The  end-of-line  stations  utilize  the  WCC  software  in  much  the  same  way  as 
the  front-of-line  systems.  Proving  the  WCC  application  on  these  stations  was 
planned  for  phase  III  to  allow  fixturing  to  be  completed  for  these  processes 
and  to  allow  time  to  test  various  integration  approaches.  The  EOL  stations 
provide  the  opportunity  to: 

•  Test  the  WCC  functions  in  greater  detail. 

•  Test  the  ability  to  run  the  WCC  and  a  current  CIM  application 
simultaneously. 

•  Test  the  ability  to  integrate  standard  WCC  function  calls  to  existing 
software. 

The  operational  scenario  for  each  station  is  almost  identical  to  those  outlined 
in  Phase  II  with  the  exception  of  manual  board  scanning.  The  manual  board 
scanning  at  the  router  and  ICT  involve  scanning  the  individual  serial 
numbers  rather  than  panel  numbers.  Once  the  two  sides  are  bonded 
together,  they  will  continue  to  be  tracked  separately  through  the  system 
until  the  external  bar  code  can  be  printed.  A  short  description  of  the  Phase 
III  task  for  each  EOL  station  follows: 

•  Depanalization  Router 

The  router  removes  the  individual  circuit  boards  from  the  multi-up  panel. 

The  modification  to  the  WCC  on  this  station  was  planned  to  insure  the  correct 
fixture  is  used.  The  WCC  insures  that  the  correct  material  and  programs  are 
in  place  on  other  machines  but  the  fixture  issue  makes  the  router  unique. 

•  Bed  of  nails  in-circuit  test 

The  in-circuit  tester  does  a  node-by-node  test  of  the  assembled  board.  It  is 
the  only  major  verification  operation  employed  by  the  assembly  plant.  The 
WCC  software  must  enforce  the  pass/fail  status  from  the  ICT  insuring  that 
boards  that  fail  ICT  are  not  allowed  to  proceed  in  the  process. 

•  End-of-Line  Assembly 

There  are  a  number  of  WCC  stations  involved  in  the  final  assembly  of  this 
product.  These  operations  generically  apply  adhesives  or  coatings,  oven  cure, 
hot  bar  soldering,  repair  and  final  mechanical  assembly.  The  unique 
attributes  of  these  stations  include  the  implementation  of  multiple  operations 
at  each  WCC  and  the  planned  change  over  between  every  unit.  The  WCC  was 
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designed  to  allow  multiple  operations  but  the  end-of-line  stations  provided 
the  best  opportunity  to  complete  the  testing  and  deployment  of  this 
capability.  A  unique  method  of  using  the  setup  and  change  over  features 
was  implemented  for  phase  III.  When  sub-assemblies  are  physically  joined 
(core  bond)  they  are  also  logically  joined  in  the  database  system.  On  the 
MPCL  products,  however,  there  were  production  engineering  reasons  for 
providing  physical  attachment  at  the  start  of  the  final  assembly  area  but 
delay  the  logical  joining  until  the  end  of  final  assembly. 

•  Label  Printer 

The  label  printer  is  the  point  where  the  two  subassemblies  are  logically 
joined  and  assigned  a  unique  serial  number.  This  is  despite  the  fact  that  the 
sub-assemblies  were  physically  joined  many  steps  earlier  in  the  process. 

The  team  made  the  decision  to  test  the  ability  of  standard  functions  to  be 
employed  in  existing  commercial  software  on  this  work  cell.  At  all  other 
operations,  existing  software  has  always  been  added  to  our  WCC  application 
resulting  in  a  single,  very  flexible  and  powerful  application.  This  is 
considered  desirable  in  almost  all  cases.  There  are  instances,  however, 
where  it  will  be  much  more  effective  to  update  existing  software  by  adding 
the  MPCL  functions  to  the  older  code  in  lieu  of  adding  it  to  the  WCC. 

Therefore,  in  one  case  the  team  took  the  current  label  printer  software  and 
replaced  the  existing  database  functions  with  the  standard  MPCL  functions. 

•  Pack  Station 

The  pack  station  is  the  final  operation  prior  to  shipment  to  San  Diego  for  final 
testing.  A  third  integration  technique  was  tested  on  this  station.  Since  a 
mature  pack  system  existed  in  the  current  commercial  operation,  a  dual 
application  approach  was  chosen  that  would  require  both  the  WCC  and  the 
current  pack  software  to  run  concurrently  for  the  one  operation.  The 
planned  task  would  be  to  minimize  changes  to  either  the  pack  or  the  WCC 
code  and  to  configure  the  WCC  code  in  such  a  way  as  to  allow  both  systems  to 
run  simultaneously.  Since  the  old  software  accesses  its  routing  verification 
database  via  RS-232,  a  cable  would  literally  be  run  from  one  port  connected 
to  the  pack  software  to  another  port  on  the  same  machine,  operated  by  the 
WCC  application. 

Methodology 

The  combined  goals  of  integrating  the  end-of-line  and  the  goal  of  testing 
integration  approaches  were  tested  independently  due  to  the  number  of 
operations  used  in  the  end-of-line.  In  each  case  integration  would  be 
accomplished  with  minimal  change  to  the  application  software  and  no 


27 


changes  to  the  data  model.  This  is  realistic  given  the  mature  state  of  the  data 
model  and  the  configuration  of  the  WCC  application. 

Where  custom  integration  is  required,  the  standard  functions  and  approaches 
were  used. 

Results 

The  goals  of  integrating  these  final  operations  and  the  testing  of  integration 
approaches  were  both  completed  successfully.  If  an  integration  approach 
failed,  we  would  simply  apply  another  method  to  achieve  the  needed 
functionality.  This  back  up  plan  was  however  not  needed  since  each  level  of 
integration  was  deployed  successfully.  Notes  on  each  approach  are  outlined 
under  the  specific  application  as  follows: 

•  Depanalization  Router 

The  router  uses  the  WCC  application  in  the  normal  fashion.  This  operation  is 
the  first  production  test  of  the  system’s  ability  to  track  a  panel  of  units,  then 
track  the  individual  units  after  depanalization.  The  router  WCC  is  uniquely 
responsible  for  marking  the  panel  numbers  as  complete  and  enabling  the 
individual  units  to  move  to  the  next  operation  in  the  process.  It  also 
confirms  the  correct  fixture  and  program  are  in  place  prior  to  starting  the 
operation.  Despite  some  problems  with  customizing  the  router,  the  team  was 
able  to  implement  a  workable  solution. 


•  Bed  of  Nails  In-circuit  Tester 

This  tester  would  use  the  WCC  application  in  the  normal  fashion.  This 
operation  is  the  only  production  operation  that  fully  uses  the  pass/fail 
aspects  of  the  CIM  routing  functions.  This  insures  that  a  board  that  fails  will 
not  proceed  through  the  process. 

•  Label  Printer 

Integrating  the  label  printer  station  involved  using  existing  software  and 
adding  a  minimum  of  MPCL  functions.  The  team  automotive  business 
currently  uses  label-printing  software  on  many  production  stations  providing 
relatively  mature  software  and  interfaces.  The  label  printer  stations  support 
the  following  MPCL  functions: 

•  Select  the  correct  schedule  from  the  MPCL  data  model. 

•  Check  prior  step  status  of  a  scanned  unit  (should  it  be  at  the  label 
printer). 

•  Create  the  top-level  serial  number  in  the  MPCL  system. 
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•  Complete  the  two  (side  A  and  B)  serial  numbers  in  the  system  to 
prevent  further  processing  of  the  individual  boards.  (Dropped  to  allow 
defect  entry  at  remote  plant) 

•  Add  information  to  the  system  to  tie  the  completed  units  to  the  top- 
level  number.  The  completed  units  are  then  sub-assemblies  of  the 
final  serialized  unit. 

•  Print  two  labels  for  each  unit  (one  for  the  module,  one  for  the  shipping 
bag) 

•  Save  tracking  data  on  the  new  serial  numbers  to  the  database  (date 
and  time  through  the  process) 

Minor  interface  modifications  were  needed  since  the  production  software 
assumes  there  is  only  one  serial  number  subassembly.  The  modification  will 
allow  the  scanning  of  two  units  prior  to  printing  the  label.  The  software 
would  also  confirm  that  the  two  subassembly  serial  numbers  can  be  joined 
(cannot  attach  FEC  A  to  PNP  B  for  example). 

The  existing  code  was  modular  and  well  written  making  the  integration  task 
straightforward.  The  existing  program  first  was  converted  to  32  bit  to  be 
compatible  with  the  MPCL  database  functions.  Then  each  function  was 
added  and  tested  without  major  issue. 

•  Pack  Station 

The  commercial  business  has  a  mature  pack  station  application  that  was 
selected  for  this  integration  test.  The  integration  plan  for  pack  is  to  use  the 
current  commercial  software  without  modification  by  running  the  normal 
MPCL  WCC  program  in  the  background.  Thus  the  user  would  only  see  the 
pack  software  with  its  familiar  interface.  To  accomplish  the  goal  of  using  the 
pack  software  without  modification,  the  following  steps  were  required: 

•  Modify  the  WCC  application  to  look  like  an  RS-232  prior  step  port  to 
the  pack  software. 

•  Set  up  the  current  software  to  run  MPCL  product,  including  the 
commercial  databases. 

•  Wire  the  RS-232  ports  to  allow  the  pack  software  to  interface  with  the 
MPCL  system. 

•  Test  the  integrated  system. 

Step  1  involves  a  minor  change  to  the  WCC  application.  Part  of  the  original 
WCC  specification  was  the  ability  to  integrate  with  the  current  RS-232  prior- 
step  system  as  a  client.  This  step  requires  the  WCC  to  act  like  an  old  prior- 
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step  server  when  connected  to  the  pack  system.  The  operational  scenario 
would  proceed  by  first  scanning  the  board  into  the  pack  software.  The  pack 
software  would  request  the  status  of  the  module  over  the  RS-232  connection 
as  it  does  today.  The  RS-232  connection  would  be  routed  into  the  same 
machine  and  would  be  answered  by  the  WCC  software  after  checking  with 
the  Oracle  database.  The  WCC  software  would  handle  all  normal  database 
functions  and  the  operator  can  click  on  the  WCC  icon  to  view  schedule,  setup 
and  process  instruction  data,  or  click  on  the  pack  software  to  perform  the 
final  pack  operation. 

Step  2  requires  simply  setting  up  the  commercial  configuration  databases  to 
run  the  MPCL  product.  Since  we  did  not  modify  the  pack  software,  it  must 
be  setup  with  information  on  the  allowed  serial  numbers,  prior  step  codes 
and  pack  carton  quantities. 

Step  3  is  just  a  short  piece  of  RS-232  cables  going  from  Port  2  to  Port  3  on 
the  same  machine.  The  pack  software  is  programmed  to  use  Port  2  while  the 
WCC  uses  Port  3.  This  interface  is  all  that  is  required  for  the  two  systems  to 
communicate  and  function  correctly. 

1.3.13  Demonstrating  Remote  Production  Features 
Task  Description 

The  MPCL  system  is  designed  to  be  accessible  from  anywhere  on  the  planet 
that  has  either  a  phone  line  or  an  IP  Internet  connection.  The  only  planned 
production  use  of  this  feature  is  the  final  testing  processes  in  San  Diego.  The 
task  therefore  is  to  set  up  the  full  Factory  Control  System  and  the  Work  Cell 
Controller  in  San  Diego.  Once  setup,  the  factory  system  was  tested,  including 
reports  and  system  configuration.  The  WCC  application  was  configured  to 
run  the  final  four  verification  operations  for  production  units. 

Methodology 

Installation  in  San  Diego  was  performed  in  the  same  fashion  as  in  Marshall. 
The  San  Diego  -operations  were  configured  as  part  of  the  production  route 
that  starts  at  the  end-of-line  label  printer  (the  route  starts  there  when  the 
top-level  serial  number  is  created). 

Results 

Installation  of  the  full  system  in  San  Diego  proceeded  without  major  issue. 
The  database  was  accessed  over  the  phone  lines  and  provided  acceptable 
response  times.  The  factory  and  WCC  applications  were  moved  to  a  local 
machine,  however,  to  improve  performance. 
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Defect  entry  became  an  issue  since  San  Diego  has  the  need  to  either  enter 
defects  against  the  unit  (missing  screw  for  example)  or  against  an  individual 
board  (bad  U5).  This  need  was  not  anticipated  and  an  approach  was 
developed  that  would  1)  display  the  outside  package  if  the  outside  serial 
number  was  scanned  and  2)  display  the  detailed  PCB  graphic  if  the  inside 
label  was  scanned.  This  impacted  the  label  print  station  slightly  since  the 
stations  completed  the  inside  unit  during  label  print.  It  also  impacted  the 
WCC  application  since  it  would  have  to  provide  both  interfaces. 

1.4  Conclusions  and  Recommendations  _ 

Overall,  the  MI  project  has  been  completed  successfully.  Phase  III  provided 
sufficient  time  to  complete  training  and  deployment  of  all  the  system 
elements.  The  current  system  is  ready  for  any  production  use  or  new  design 
from  the  program  design  center  in  San  Diego.  The  low  volume  of  production 
from  these  sources  will  make  system  training  and  support  an  issue.  Further 
deployment  of  the  MPCL  CIM  system  will  eliminate  this  issue  by  more 
frequent  use  thereby  building  a  larger  group  of  trained  system  operators. 

Actions  required  to  expand  the  CIM  system  beyond  the  current 
implementation  include  developing  interfaces  to  other  design  centers  and 
deploying  the  production  system  to  other  commercial  lines 
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Appendix  1  -  Manufacturing  Line  Scenario 

1.  Manufacturing  Line  Scenario 

Appendices  1  and  2  focus  CIM  Operational  Scenarios  -  the  Manufacturing  Line  Scenario  and 
Operational  Scenarios.  The  Manufacturing  Line  Scenario  provides  an  overview  of  the  manufacturing 
line  along  with  the  common  elements  and  major  issues  addressing  the  CIM  System.  The 
Operational  Scenario  provides  a  detailed  description  of  the  operator  interaction  with  the  major 
components  of  the  CIM  System.  In  support  of  the  MPCL  CIM  Project,  Flex  Line  3  will  be  used  at 
the  Marshall  Plant 

Flex  Line  3  as  discussed  here  is  currently  in  transition.  Based  on  data  currently  available,  we  are 
assuming  what  process  machines  this  project  will  use.  The  MPCL-PT  Team  has  selected  the  Flex 
Line  3  as  the  line  to  produce  and  MPCL  PWA.  The  stations  to  be  used  are: 

1 .  Bar  Code  Label  Application  Station 

2.  PWA  Board  Handling  (Loader)  Station 

3.  Screen  Print  (MPM  UP  3010)  Station 

4.  Adhesive  Dispensing  Station 

5.  Inspection  Station 

6.  Off-line  Reel  Loader  Station 

7.  Fine  Pitch  Chip  Shooter  (MV  II)  Station 

8.  Ball  Grid  Array  Top  Side  Placement  (Universal  GSM)  Station 

9.  Inspection  Station 

10.  Reflow  Oven  (Electrovert  ATMOS  CR2000)  Station 

11.  Inspection  /  Touch  Up  Station 

12.  Board  Label  Application  Station 

13.  Wash  (Westkleen)  Station 

14.  PWA  Depanel  Station 

15.  In-Circuit  Test  (GENRAD)  Station 

16.  Core  Bond  Station 

1 7.  Hot  Bar  Station 

1 8.  Flex  Attach  Station 

19.  Inspection  /  Touch-Up  Station 

20.  Repair  Station 

21.  Conformal  Coat  Station 


22.  Final  Assembly  Station 

23.  Pack  and  Ship  Station 

These  stations  are  laid  out  in  the  form  of  a  “line”  concept  (as  shown  in  the  figure  below)  so  that  a 
Printed  Wire  Assembly  (PWA)  starts  on  one  end  of  the  line  and  works  its  way  to  the  other  end. 


The  above  sequence  provides  the  general  flow  of  the  PWA  starting  at  the  Bar  Code  Label 
Application  and  ending  at  the  Pack  and  Ship  Station.  The  following  sub-sections  discuss  the  major 
operational  items  and  issues. 
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Figure  1-1.  Flex  3  IBP  Line  Layout 
1.1  Manufacturing  Stations  and  Operations 

Each  of  the  physical  locations  where  work  is  performed  is  considered  a  “station”  or  a  manufacturing 
location.  Wherever  a  PWA  is  inspected,  tested,  added  to  or  changed,  that  functional  entity  is  an 
“operation”.  Typically  a  station  performs  one  operation,  however  that  is  not  strictly  adhered  to. 
For  reasons  of  production  there  may  be  many  “stations”  that  perform  the  same  “operation”. 
Conversely,  for  activities  that  are  sporadic,  or  do  not  require  significance  amount  of  work,  there  may 
be  many  “operations”  performed  at  a  single  “station”. 

In  this  document  a  simple  one  to  one  approach  is  assumed.  However,  the  design  of  the  CIM 
System  should  not  be  restricted  as  such.  It  should  allow  many  stations  to  perform  the  same 


33 


operation  and  support  many  operations  to  be  performed  at  the  same  station  with  minimal  Factory 

Control  System  (FCS)  configuration. 

1.2  CIM  MPCL  Vs.  CIM  Today  Mode  of  Operation 

The  focus  of  the  operational  scenario  is  to  define  how  each  of  the  stations  will  operate  in  "CIM 

MPCL"  mode.  Each  of  the  stations  shall  be  "operable"  in  a  "Original  CIM"  mode. 

The  default  CIM-MPCL  mode  of  operation  will  have  the  following  characteristics: 

1 .  In  the  "CIM  MPCL"  mode  of  Operation,  a  Workcell  Controller  (WCC)  of  the  CIM  system 
will  control  the  traffic  flow  using  a  “black  box”  approach  to  which  the  input  and  output  of 
the  SMEMA  interface  shall  plug  into.  Removal  of  the  SMEMA  interface  between  the 
machine  and  the  conveyor  PLC  will  result  in  the  "original  CIM"  mode  of  operation  for  traffic 
control  of  the  PWA. 

2.  In  the  "CIM  MPCL"  mode  the  WCC  will  explicitly  request  the  conveyor  to  be  stopped  as 
part  of  its  WI P/Changeover  transactions  using  the  SMEMA  interface.  In  "Original  CIM" 
mode,  the  operation  shall  be  executed  without  product  stopping. 

3.  Once  "CIM  MPCL"  is  operational,  running  a  cell  in  the  "Original  CIM"  mode  will  require  a 
signed  deviation. 

1.3  Physical  Attributes  of  a  Station 

Each  station  on  the  line  shall  consist  of  the  following  pieces  of  equipment: 

1 .  A  Bar  Code  Reader  at  the  input  conveyor  to  read  the  PWA  bar  code  while  the  PWA  is  still 
moving.  The  decoded  data  will  be  sent  to  the  WCC  PC  via  a  serial  connection.  The  details 
of  how  this  data  is  received  using  a  serial  port,  networks,  etc.  is  left  up  to  the  design  / 
prototype  phase  of  the  project. 

2.  The  input  and  output  conveyors  are  to  be  controlled  by  PLC’s.  Communications  from  the 
PLC  to  WCC  PC  will  be  “direct  digital”  using  the  SMEMA  interface. 

3.  The  WCC  PC  at  the  stations  shall  be  a  486  PC  or  higher  with  a  minimum  of  16MB  of 
Memory.  It  shall  be  networked  to  the  other  WCC  PC’s  on  the  Manufacturing  Line  and  the 
Factory  Control  System.  The  network  backbone  and  file  system  is  under  review  and  will  be 
finalized  as  part  of  the  detailed  design  effort. 

4.  The  WCC  PC  shall  communicate  with  the  local  process  machine  using  the  machine  interface 
port  (if  one  is  available).  At  minimum  the  interface  is  to  support  program  select,  start  and 
stop.  If  this  functionality  is  not  present  for  any  particular  machine,  the  user  interface  will  be 
so  configured  to  allow  the  “messages”  to  go  to  the  user  instead. 

1.4  Operational  Overview  of  a  Station 

Each  process  machine  station  on  the  line  shall  deal  with  the  following  operational  scenario: 
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1.  A  Bar  Code  Reader  at  the  input  conveyor  will  read  the  PWA  bar  code  while  the  PWA  is  still 
moving.  The  decoded  data  is  configured  so  that  the  WCC  PC  receives  the  data  immediately 
(less  than  0.1  seconds). 

2.  The  WCC  PC  will  have  supervisory  control  over  the  SMEMA  Interface  which  provides 
override  and  sensing  capability.  This  gives  the  WCC  PC  the  control  to  determine  which 
signals  to  pass  and  which  are  to  be  held  up  based  on  the  WIP  and  Changeover  status  of  the 
station. 

3.  After  successfully  scanning  each  PWA,  the  “prior”  step  check  shall  be  performed. 

The  checks  include  the  following: 

•  Check  that  Prior  Step  has  been  accomplished.  Note  that  the  “prior”  step  for  a  PWA 
may  be  different  for  each  type  of  PWA  and  that  its  “route”  data  needs  to  be  accessible 
by  the  “prior”  step  function. 

•  Check  that  the  PWA  is  not  on  a  “hold”  status.  A  unit  may  be  on  a  hold  status  due  to  a 
number  of  reasons  including  QA  Hold,  Unacceptable  number  of  component  failures,  or  a 
product  issue. 

•  Once  the  Check  is  done,  the  PWA  is  “Wiped  In”  to  the  station  with  its  time  stamp  noted 
(i.e.  assuming  no  product  changeover  -  this  is  discussed  in  detail  below). 

4.  When  a  new  product  type  is  introduced  at  the  "first"  station  on  the  line,  the  WCC  PC 
should  send  a  notification  to  the  operator.  This  request  for  "OK  to  Proceed"  will  require  a 
supervisory  password.  This  will  provide  the  opportunity  to  either  accept  or  override  the 
product  changeover.  Once  the  first  station  has  been  authorized  to  proceed  with  the 
changeover,  all  subsequent  stations  on  the  "route"  shall  be  given  advance  notification  that  a 
product  changeover  is  planned.  In  addition,  when  the  product  change  over  is  accomplished 
at  this  station,  the  next  station  on  the  route  shall  get  an  "impending"  changeover  signal.  This 
will  allow  the  operator  at  that  downstream  station  to  prepare  any  product  changeover  items 
that  will  be  necessary  prior  to  PWA  arrival,  thus  minimizing  down  time. 

5.  To  support  product  change  over,  the  WCC  PC  will  get  all  appropriate  changeover  data  from 
the  database.  It  will  then  validate  the  data  with  what  is  on  the  station.  Appropriate  user 
screens  will  allow  the  operator  to  validate  that  the  product  change  over  is  complete.  This 
validation  shall  be  in  the  form  of  a  check  list  displayed  on  the  WCC  PC,  that  will  tell  the 
operator  items  such  as  part  programs,  fixture/tooling  changes,  etc.  that  need  to  be 
completed.  Where  ever  possible,  these  will  be  designed  to  be  "verifiable",  such  as  bar  coding 
or  clicking  the  appropriate  box. 

6.  Once  the  PWA  unit  is  ready  to  enter  the  station,  the  preferred  method  of  starting  program 
execution  is  for  the  WCC  PC  to  notify  the  Machine  which  programs  to  download,  select  and 
execute.  In  a  few  circumstances  this  may  not  be  possible  due  to  the  complexity  of  the 
machine  interface.  In  that  case  the  user  will  be  prompted  to  “manually”  load  and  start  the 
appropriate  program. 
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7.  Once  the  machine  is  finished  with  the  PWA,  it  will  use  the  SMEMA  interface  to  provide  the 
OK  signal  to  release  the  PWA  onto  the  output  conveyor.  Once  the  PWA  is  on  the  output 
conveyor,  the  SMEMA  interface  will  “signal”  the  WCC  PC  that  the  PWA  is  on  the  output 
conveyor.  The  WCC  PC  will  than  get  the  time  stamp  and  send  out  a  Wip  Out  Transaction 
to  update  the  database. 

8.  In  the  event  of  feeder  replenishment  or  changeover  to  a  different  component,  the  WCC  PC 
will  provide  a  mechanism  to  “validate”  that  the  correct  component  part  was  placed  in  the 
correct  feeder  in  the  correct  location  on  the  machine.  The  details  of  this  design  shall  be 
finalized  in  the  design/prototype  phase  of  the  project. 

9.  In  the  event  that  a  station  has  been  idle  for  a  configurable  period  of  time  (~3  hours),  a 
product  changeover  will  be  forced  on  the  machine.  This  will  allow  for  any  maintenance  or 
down  time  items  to  be  purged  and  a  valid  production  program  be  run. 

10.  Component  Consumption  transactions  will  be  handled  using  a  set  of  the  Manufacturing  Bill 
of  Material  tables  for  each  Operation  with  current  sequences  for  machine  locations.  A 
component  consumption  application  on  the  WCC  PC  will  support  updates  to  the  databases 
with  “trace”  data. 

1.5  Functional  Overview  of  a  Machine  Interface 

Each  of  the  process  machine  stations  on  the  line  will  have  "interface  drivers"  that  provides 
communications  and  functional  support.  The  following  machine  types  with  their  interface  needs 
and  functionality  will  be  used  by  the  MPCL  Program. 

1.6  Machine  Types 

1.  MPM  UP  3010  Screen  Printer 

2.  Adhesive  Dispensing  Machine 

3.  Panasonic  MV-II  TopSide  Chip  Shooter 

4.  Universal  GSM  Ball  Grid  Array  Placement  Machine 

5.  Electrovert  ATMOS  2000  Reflow  Oven 

6.  Westkleen  Cleaner 

7.  GenRad  2284  In-Circuit  Tester  Station 

8.  CenCorp  TR4000  Depanelling  Machine 

1.7  Features  /  Functions  List 

1 .  Program  Changeover  by  Product  Change.  Either  due  to  new  product  or  different  product 

revision. 

2.  Product  Verification  and  /  or  Changeover  if  the  Station  is  "idle"  for  "X"  time.  Typically  this 

time  shall  be  about  3  hours. 

3.  Product  Changeover  on  Initialization  or  Restarting  of  a  Station. 
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4.  As  part  of  Product  Changeover,  need  to  verify  that  part  feeder  is  loaded  into  the  correct  "slot" 
in  the  machine.  This  will  also  be  supported  where  there  are  multiple  "Z"  (feeder  carriages)  axes 
with  different  "Sequence"  codes. 

5.  Need  to  verify  that  "part"  is  scanned  to  correct  feeder  in  an  on-line  or  off-line  mode 

6.  Routing  Verification  for  each  PWA  is  to  include  the  unit  being  valid,  not  on  Hold,  not 
Scrapped,  "X"  number  of  fails  through  a  station,  and  must  be  processed  within  a  given  amount 
of  time  from  a  previous  station. 

7.  Machine  and  part  data  collection  to  be  supported  using  the  machine  interface  as  much  as 
possible. 

8.  Defect  Data  to  be  manually  entered. 

9.  Traceability  using  product  scanned  at  the  station  and  parts  scanned  as  discussed  earlier  with 
sequence  codes  for  lot  Traceability. 

10.  Advance  and  Immediate  notification  for  product  changeover  to  be  based  on  routings,  and  not 
physical  line  stations. 

11.  System  must  support  failover  if  the  main  Factory  Control  System  database  server  goes  down. 

12.  The  WCC  PC  database  server  is  to  support  transient  data  and  be  self  maintaining.  The  data  is 
to  be  "rolled"  up  and  /  or  purged  as  the  PWA  is  finished  and  completes  the  routing. 

13.  The  User  Interface  at  the  machine  stations  will  support  multimedia  files  for  support  setup  and 
build  instructions. 

14.  The  WCC  PC  will  interface  with  the  conveyor  PLC  using  a  SMEMA  interface  between  the 
process  machine  and  the  conveyor.  The  WCC  PC  will  be  the  overriding  traffic  controller. 

15.  Access  to  the  FCS  will  be  made  available  to  the  users  via  their  desktop  PC’s. 


37 


Appendix  2  -  Operational  Scenarios 


2.  Operational  Scenarios 

For  each  station  on  the  manufacturing  line,  the  following  provides  a  detailed  Operation  Scenario 
along  with  Issues  and  Assumptions.  Issues  in  subsequent  sections  are  not  repeated,  but  will  assume 
to  be  covered  when  first  identified.  In  addition,  general  operational  scenario  related  to  "prior"  step 
check  and  product  changeover  were  discussed  in  Appendix  1.  These  will  be  briefly  mentioned  in  the 
detailed  scenarios  to  provide  specific  information  related  to  that  operation  and  to  provide 
continuity. 

2.1  Bar  Code  Label  Application  Station 

2.1.1  Overview 

The  Bar  Code  Label  Application  Station  is  where  an  operator  generates  Kapton  labels  that  are 
applied  to  the  PWA.  Typically  a  PWA  consist  of  two  individual  circuit  card  assembly's,  with  only 
one  bar  code  on  the  breakaway  to  identify  the  PWA  panel.  These  Kapton  labels  are  applied  to  the 
PWA  and  stay  with  it  until  the  Depanel  Operation  where  individual  labels  on  the  circuit  boards  are 
used  to  track  it  and  the  breakaway  is  disposed  of. 

The  station  consists  of  the  following: 

•  A  WCC  PC  that  interacts  with  the  plant  wide  FCS  system  and  the  operator. 

•  A  Bar  Code  Printer  capable  of  printing  Kapton  Labels  for  PWA's.  The  interface  between 
the  WCC  PC  and  the  Printer  is  RS232  communications. 


Network 


PWA  Flow 
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2.1.2  Operating  Scenario 

1 .  The  Operator  will  determine  which  type  of  PWA  and  quantity  to  build  on  the  line.  Based 
on  the  list  of  valid  units,  the  operator  will  print  the  appropriate  number  of  PWA  labels. 

2.  The  User  Interface  screen  shall  support  password  protection  so  that  only  authorized 
operators  may  create  the  labels.  Units  are  sequenced  automatically  by  the  Cell  based  on 
previous  serial  numbers.  These  numbers  are  to  be  Julian  Date  and  Serial  Number  based  along 
with  a  Product  Identifier.  The  Cell  shall  provide  the  Operator  with  information  as  to  what  is 
a  valid  engineering  build  for  the  line. 

3.  Once  the  labels  are  defined,  the  WCC  PC  shall  print  the  labels  for  the  operator  to  place  on 
the  PWA.  If  the  operator  needs  to  print  additional  labels  due  to  spoilage,  they  will  be  able 
to  "re-print"  them  with  the  proper  password. 

4.  The  Production  Planner  will  define  the  quantity  scheduled  to  be  built  by  day,  by  line  and  by 
Product  Type.  The  Operator  shall  not  be  authorized  to  modify  this. 

2.1.3  Issues  /  Assumptions 

1 .  The  PCS  application  suite  shall  provide  a  Dispatch  List  of  valid  repetitive  schedule  and 
work  orders  along  with  a  Valid  List  of  Part  Numbers  /  Product  ID's  and  production 
priorities. 

2.  Verification  of  the  bar  code  labels  printed  will  be  performed  on  a  continuos  basis.  This  shall 
be  accomplished  by  having  this  cell  be  integrated  with  the  next  PWA  board  handler  cell 
which  will  perform  the  validation  prior  to  allowing  the  panels  to  move  downstream. 


2.2  PWA  Board  Handling  (Loader)  Station 
2.2.1  Overview 

The  Board  Handling  Station’s  purpose  is  to  take  the  bare  PWA's  and  put  them  of  the  conveyor. 
When  downstream  demand  requests  a  PWA;  they  are  released  on  to  the  output  conveyor. 

The  station  consists  of  the  following: 

•  Automated  Board  Loader  capable  of  loading  a  variety  of  PWA’s. 

•  Supports  PLC  Communications  using  SMEMA  interface. 

•  A  Bar  Code  Scanner  using  a  RS232  interface. 
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2.2.2  Operating  Scenario 

1 .  The  Operator  stacks  a  set  of  labeled  PWA  assemblies  into  the  loader.  The  PWA  Loader 
loads  them  on  to  the  in-feed  conveyor  based  on  demand. 

2.  The  Board  Handler  Controller  based  on  downstream  demand  will  release  the  boards  onto  the 
conveyor. 

3.  Exceptions  shall  be  handled  by  the  Board  Handler  Controller  and  a  warning  beacon  shall  be 
used  to  notify  the  Operator.  Exceptions  include  No  Read,  Duplicated  bar  code,  etc. 

4.  When  a  new  product  type  is  introduced  at  the  "first"  station  on  the  line,  the  WCC  PC  will 
notify  the  operator  that  a  changeover  is  at  the  first  station.  This  request  for  "OK  to 
Proceed"  will  require  a  supervisor  password.  This  will  provide  an  opportunity  to  either 
accept  or  override  the  product  changeover. 

5.  Once  the  first  station  has  been  authorized  to  proceed  with  the  changeover,  all  subsequent 
stations  on  the  "route"  shall  be  give  advance  notification  that  a  product  changeover  is 
planned.  In  addition,  when  the  product  change  over  is  accomplished  at  this  station,  the  next 
station  on  the  route  shall  get  an  "impending"  changeover  signal.  This  will  allow  the  operator 
at  that  downstream  station  to  prepare  for  product  changeover,  thus  minimizing  setup  down 
time. 

2.2.3  Issues  /  Assumptions 

1 .  Currently  there  is  no  interaction  with  the  CIM  System.  It  is  a  PLC  controlled  machine.  It 
will  be  controlled  using  the  SMEMA  interface. 
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This  station  is  to  be  "controlled"  by  the  Barcode  Label  Application  Station  to  support  label 
verification. 

This  station  will  be  the  “first”  station  for  “advance  notification”  function  for  changeover 
control 

This  station  and  the  Barcode  Label  Application  Station  will  use  the  same  WCC  PC  and  user 
display. 

Advance  "new"  and  "impending"  notification  is  to  be  designed  using  a  "route"  line  concept 
where  each  station  will  send  to  the  next  station  downstream. 

2.3  Screen  Print  (MPM  UP  3010)  Station 
2.3.1  Overview 

The  Screen  Print  Station  is  used  to  screen  (apply)  solder  paste  to  the  bare  PWA.  The  process 
typically  consists  of  a  fine  steel  screen  held  in  a  fixture  assembly  being  positioned  on  top  of  the 
PWA.  A  vision  system  uses  fiducials  to  accurately  place  the  screen  onto  the  PWA.  Based  on  the 
program,  the  "squeegee"  then  kneads  the  solder  paste  and  spreads  it  over  the  steel  screen.  The  mesh 
in  the  steel  screen  allows  only  selected  pad  regions  to  receive  the  solder  paste.  Typically  a  vision 
system  is  then  used  to  provide  spot  checking  of  certain  key  locations  for  correct  solder  paste 
adhesion.  If  the  adhesion  is  not  sufficient,  an  alarm  is  generated  for  operator  intervention. 

The  station  consists  of  the  following: 

•  Semi-automatic  MPM  UP  3010  Screen  Printer  capable  of  a  communications  interface  based 
on  the  SECS-I  protocol  over  a  RS232  port.  The  Message  level  functionality  is  proprietary 
to  MPM  and  support  Program  Upload/Download,  Program  Select,  and  Program  Complete 
Status. 

•  PLC  Communications  using  the  SMEMA  interface  and  direct  I/O  to  the  MPM  Controller. 

•  A  WCC  PC  that  interacts  with  the  plant  wide  PCS  system,  machine  controller  and  PLC. 

•  A  Barcode  Reader  (BCR)  that  is  positioned  at  the  entry  of  the  Cell  with  stop  capability  to 
provide  WIP  functionality  and  support. 


2. 

3. 

4. 
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.2  Operating  Scenario 

1 .  The  BCR  is  tripped  by  the  PWA  arriving,  and  resulting  in  the  BCR  scanning  the  bar  code. 

At  the  same  time  this  sensory  trigger  shall  stop  the  conveyor  from  moving  further.  The 
scanned  bar  coded  input  shall  be  input  in  the  WCC  PC. 

2.  The  WCC  PC  receives  this  bar  code  and  starts  a  series  of  checks  on  the  PWA  including  valid 
PWA,  correct  current  location,  work  order  is  OK  to  process,  if  unit  is  OK  to  process,  and  if 
change  over  is  needed  for  the  cell. 

3.  Exceptions  shall  be  smartly  handled  by  the  WCC  PC  as  discussed  in  section  2  and  if 
Operator  attention  is  required,  it  shall  so  be  requested. 

4.  If  no  changeover  is  needed,  the  WCC  PC  will  direct  the  PLC  using  the  SMEMA  interface 
with  an  OK  to  Release  and  the  PLC  will  release  the  PWA  onto  the  input  conveyor  of  the 
process  machine. 

5.  When  the  PLC  releases  the  PWA  onto  the  input  conveyor  of  the  process  machine,  an  event 
will  be  generated  by  the  WCC  PC  that  the  PWA  has  been  released.  This  will  result  in  the 
WCC  PC  time  stamping  the  WIP-IN  time  for  the  particular  unit.  It  will  then  update  the  PCS 
database  with  this  data. 

6.  To  support  product  change  over,  the  WCC  PC  validation  shall  include: 

•  Bar  Coded  Screen  Fixture. 

•  Program  to  run  which  validates  the  Screen  with  matching  fiducials. 

•  Solder  Paste  Changes,  or  kneading. 


2.3.3  Issues  /  Assumptions 

1 .  We  are  going  to  be  using  bar  code  readers  with  fast  /  wide  scanning  to  support  on  the  fly 
scanning. 

2.  Assumption  is  that  the  master  controller  in  "releasing"  the  PWA  into  the  Cell  is  the  PLC. 
Overriding  traffic  control  is  to  be  provided  by  the  WCC  PC  using  the  SMEMA  interface. 

3.  The  data  on  the  items  necessary  for  product  change  over  are  to  be  entered  in  the 
Configuration  Management  System  of  the  PCS  as  individual  data  items  as  well  as  a  check  list 
of  manufacturing  instruction  that  will  be  displayed. 

4.  How  involved  should  the  "verification"  be  for  supporting  product  change  over?  Simple  with 
dependence  on  operator  as  central  controlling  link,  or  Constrained  with  minimal  dependence 
on  operator,  and  all  operator  work  being  "verified"?  Assumption  is  this  level  of  effort  is 
being  evaluated  for  addressing  the  feeder  verification. 


2.4  Adhesive  Dispensing  Station 
2.4.1  Overview 

The  Adhesive  Dispensing  Station’s  role  is  to  apply  beads  of  adhesive  on  the  PWA  so  that  the 
bottom  side  surface  mount  components  may  bond  to  the  PWA.  These  than  get  wave  soldered  later 
in  the  process  to  achieve  the  electrical  bonding. 

The  station  consists  of  the  following: 
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•  Adhesive  Dispenser  capable  of  Program  upload  /  download,  Select  and  Start. 

•  PLC  Communications  using  a  SMEMA  interface  and  direct  I/O  to  the  Adhesive  Dispensing 
Station  with  Controller. 

•  A  WCC  PC  that  interacts  with  the  plant  wide  PCS  system,  the  machine  controller  and  PLC. 

•  A  BCR  that  is  positioned  at  the  entry  of  the  Cell  with  stop  capability  to  provide  WIP 
functionality  and  support. 


Network 


SMEMA 


WCC 

PC 


RS232 


SMEMA 


I  I  Adhesive  Dispensing 

PWAFIow  PLC  BCR  Station  with  Controller 


2.4.2  Operating  Scenario 

1 .  Same  basic  set  of  operating  scenario  as  the  earlier  sections.  Changeover  data  from  the 
database  includes: 

•  Program  to  run. 

•  Adhesive  and  /  or  nozzles  changes,  if  any. 

2.4.3  Issues  /  Assumptions 

1 .  Should  the  Screen  Printing  and  this  Adhesive  Dispensing  Station  be  one  and  the  same,  with 
the  WCC  PC  supporting  the  two  separate  operations?  Would  this  be  better  for  the  user,  or 
keep  it  simple  with  one  WCC  PC  per  Machine  Station?  For  now  it  will  be  kept  separate. 

2.  The  Sony  Adhesive  Machine  interface  document  was  not  available,  need  to  verify  what  type 
of  machine  communications  it  supports? 

2.5  Inspection  Station 
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2.5.1  Overview 


The  Inspection  Station  is  a  manual  station.  In  this  station  an  operator  inspects  the  PWA’s  for 
defects  such  as  solder  paste  defects,  adhesive  placement  defects,  etc.  These  defects  are  noted  into 
the  defects  database  using  a  graphical  interface,  and  the  appropriate  touch  up  is  done.  Depending  on 
the  throughput,  there  may  be  more  than  one  station  performing  this  operation. 

The  station  consists  of  the  following: 

•  A  WCC  PC  based  that  interacts  with  the  plant  wide  PCS  system  and  operator. 

•  A  BCR  to  provide  WIP  functionality  and  support. 


BCR 


2.5.2  Operating  Scenario 

1 .  The  PWA  barcode  is  scaimed.  The  system  will  perform  all  the  WIP  checks  that  it  would 
normally  do  for  a  PWA  on  the  line.  Any  exception  condition  will  be  brought  to  the 
operators  attention. 

2.  If  the  PWA  status  is  OK,  the  operator  will  inspect  the  PWA  and  enter  any  defects  using  the 
defects  data  collection  application.  The  operator  will  than  be  given  the  option  to  PASS  or 
FAIL  the  PWA.  If  the  PWA  failed  it  will  be  removed  for  rework.  If  it  passed,  the  operator 
will  release  the  PWA  for  further  processing. 

3.  Using  this  interface  the  operator  will  have  the  option  of  seeing  the  trend  and  pareto  charts  of 
defects. 
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2.5.3 


Issues  /  Assumptions 


1 .  Should  this  station  be  considered  part  of  the  route?  It  is  assumed  yes,  and  that  we  have 
100%  inspection. 

2.  It  is  assumed  that  the  current  Real  Time  Feedback  System  will  be  used,  with  the  possible 
enhancement  of  hitting  the  relational  database.  In  addition,  is  the  system  to  roll  up  all  the 
defects  data  into  the  RDBMS  for  long  term  trending  and  capability  analysis? 

2.6  Off-line  Reel  Loader  Station 
2.6.1  Overview 

The  Off-line  Reel  Loader  Station  is  a  manual  station.  In  this  station  an  operator  loads  the  part 
reels  onto  the  respective  feeders. 

The  station  consists  of  the  following: 

•  A  WCC  PC  based  that  interacts  with  the  plant  wide  FCS  system  and  operator. 

•  A  BCR  to  provide  WIP  functionality  and  support. 
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2.6.2  Operating  Scenario 

1 .  The  part  reels  Part  Number  and  Lot  Number  barcodes  are  scanned.  The  system  will  perform 
all  the  WIP  and  valid  part  checks.  Any  exception  condition  will  be  brought  to  the  operators 
attention. 

2.  If  the  PWA  and  part  status  is  OK,  the  operator  shall  load  the  part  reel  onto  the  feeder.  The 
operator  will  then  scan  the  Part  Number,  Lot  Number  and  Feeder  Number. 
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2.6.3  Issues  /  Assumptions 

1 .  Should  this  station  be  considered  part  of  the  route?  It  is  assumed  yes,  and  that  we  have 
100%  inspection. 

2.7  Fine  Pitch  Chip  Shooter  (MV-II)  Station 
2.7.1  Overview 

The  Fine  Pitch  Chip  Shooter  generally  put  on  the  active  components  such  as  large  Pin  Grid  Arrays, 
ASICs  and  custom  chips  that  have  better  than  50mil  pitch  requirements.  They  generally  have  a 
vision  system  that  verifies  component  placement  using  fiducials  to  provide  the  higher  accuracy 
needed  to  place  the  fine  pitch  components. 

This  station  consists  of  the  following: 

•  Automatic  Panasonic  MV-II  SMT  Standard  Surface  Mount  Placement  Machine  capable  of 
Program  Select,  and  Program  Complete  Status.  The  interface  supported  by  this  station  is 
"proprietary"  and  using  ACK/NAK  handshake  with  checksum. 

•  PLC  Communications  using  a  SMEMA  interface  and  direct  I/O  to  the  MV-II  Controller. 

•  A  WCC  PC  that  interacts  with  the  plant  wide  FCS  system,  the  MV-II  controller  and  PLC. 

•  A  BCR  that  is  positioned  at  the  entry  of  the  Cell  with  stop  capability  to  provide  WIP 
functionality  and  support. 
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2.7.2  Operating  Scenario 
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1 .  Same  basic  set  of  operating  scenario  as  the  earlier  sections.  Changeover  data  from  the 
database  includes: 

•  Program  to  run. 

•  Any  components  and  /or  feeder  types  to  be  changed. 

•  Any  component  pick  up  nozzles  changes. 

2.7.3  Issues  /  Assumptions 

1 .  Advance  notification  will  be  handled  by  these  downstream  stations.  There  is  to  be  no 
mechanism  to  respond  to  the  "notifying"  stations  that  this  particular  stations  is  able  to  get 
ready  for  the  pending  changeover. 

2.  How  should  the  Manufacturing  Bill  of  Materials  concept  be  developed  and  implemented  at 
these  stations?  How  should  the  validation  be  performed  when  there  are  "component"  parts 
that  need  to  be  changed?  How  to  address  the  need  for  "sequence"  number  changes  as  new 
parts  are  used  to  replenish  used  components?  This  effort  being  evaluated. 

2.8  Ball  Grid  Array  -  Top  Side  Placement  (Universal  GSM)  Station 
2.8.1  Overview 

The  Ball  Grid  Array  (BGA)  technology  is  relatively  new,  and  this  machine  will  place  BGA 
packages  on  the  PWA.  They  generally  have  a  vision  system  that  verifies  the  placement  using 
fiducials  to  provide  the  higher  placement  accuracy  needed  to  place  the  BGA  components. 

This  station  consists  of  the  following: 

•  Automatic  Universal  GSM  Surface  Mount  Placement  Machine  capable  of  Program  Select, 
and  Program  Complete  Status.  The  interface  supported  by  this  station  is  "proprietary"  and 
using  ACK/NAK  handshake  with  checksum. 

•  PLC  Communications  using  SMEMA  interface  and  direct  I/O  to  the  Universal  GSM 
Controller. 

•  A  WCC  PC  that  interacts  with  the  plant  wide  PCS  system,  the  Universal  controller  and 
PLC. 

•  A  BCR  that  is  positioned  at  the  entry  of  the  Cell  with  stop  capability  to  provide  WIP 
functionality  and  support. 
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2.8.2  Operating  Scenario 

1 .  Same  basic  set  of  operating  scenario  as  the  earlier  sections.  Changeover  data  from  the 
database  includes: 

•  Program  to  run. 

•  Any  components  and  /  or  feeder  types  to  be  changed. 

•  Any  component  pick  up  nozzles  changes. 

2.83  Issues  /  Assumptions 

1 .  Is  there  any  time  period  that  needs  to  be  used  to  trigger  an  event  for  the  time  between  solder 
placement  and  the  final  component  placement?  The  assumption  is  that  this  is  a  general 
capability  and  is  configurable  by  station  as  part  of  some  station  data  or  route  data. 

2.9  Inspection  Station 
2.9.1  Overview 

The  Inspection  Station  is  a  manual  station.  In  this  station  an  operator  inspects  the  PWA’s  for 
defects  such  as,  solder  paste  defects,  adhesive  placement  defects,  etc.  These  defects  are  noted  into 
the  defects  database  using  a  graphical  interface,  and  the  appropriate  touch  up  is  done.  Depending  on 
the  throughput,  there  will  be  more  than  one  station  performing  this  operation.  Details  of  this 
station  type  are  discussed  in  section  4.5  above. 

2.10  Reflow  Oven  (Electrovert  ATMOS  CR2000)  Station 
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2.10.1  Overview 


The  Reflow  Oven  provides  the  hot  forced  air  curing  for  the  solder  paste  to  provide  the  electrical 
bond  for  the  top  side  components.  It  also  cures  the  adhesive  and  solder  paste  on  the  bottom  side 
components. 

The  station  consists  of  the  following: 

•  ATMOS  CR2000  Reflow  Oven  capable  of  Manual  Program  Select  and  Run.  The  interface 
supported  by  this  station  is  "proprietary"  and  using  ACK/NAK  handshake  with  checksum. 

•  PLC  Communications  using  SMEMA  interface  and  direct  I/O  to  the  ATMOS  Controller. 

•  A  WCC  PC  that  interacts  with  the  plant  wide  PCS  system  and  PLC. 

•  A  BCR  that  is  positioned  at  the  entry  of  the  Cell  with  stop  capability  to  provide  WIP 
functionality  and  support. 
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2.10.2  Operating  Scenario 

1 .  Same  basic  set  of  operating  scenario  as  the  earlier  sections.  Changeover  data  from  the 
database  includes: 

•  Program  Name  only. 

2.10.3  Issues  /  Assumptions 

1 .  Assumption  is  that  the  Time  of  Solder  Paste  Screening  and  this  Reflow  time  is  to  be 
monitored  at  WIP-IN  to  allow  for  Operator  Override  if  too  much  time  has  elapsed.  Don’t 
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believe  that  the  Data  Model  has  this  functionality  in  it.  Need  to  design  a  way  to  handle  this 
requirement. 

2.11  Inspection  /  Touch  Up  Station 
2.11.1  Overview 

The  Inspection  /  Touch  Up  Station  is  a  manual  station.  In  this  station  an  operator  inspects  the 
PWA’s  for  defects  such  as  missing  components,  mis-oriented  components,  solder  defects,  cleaning 
defects,  etc.  These  defects  are  noted  into  the  defects  database  using  a  graphical  interface,  and  the 
appropriate  touch  up  is  done.  Depending  on  the  throughput,  there  -will  be  more  than  one  station 
performing  this  operation. 

The  station  consists  of  the  following: 

•  A  WCC  PC  that  interacts  with  the  plant  wide  PCS  system  and  operator. 

•  A  hand  held  BCR  to  provide  WIP  functionality  and  support. 


Network 


WCC 

PC 


BCR 


2.11.2  Operating  Scenario 

1.  The  Operator  picks  up  the  PWA  and  scans  the  bar  code.  The  system  will  perform  all  the 
WIP  checks  that  it  would  normally  do  for  a  PWA  on  the  line.  Any  exception  condition  will 
be  brought  to  the  operators  attention. 

2.  If  PWA  status  is  OK,  the  operator  will  inspect  the  PWA  and  enter  any  defects  using  the 
defects  data  collection  application.  The  operator  will  than  be  given  the  option  to  PASS  or 
FAIL  the  PWA.  If  the  PWA  failed  it  will  be  removed  for  rework.  If  it  passed,  the  operator 
will  place  it  back  on  the  conveyor  for  further  processing. 


3.  Using  this  interface  the  operator  will  have  the  option  of  viewing,  storing  or  printing  the  trend 
and  pareto  charts  of  defects. 

2.11.3  Issues  /  Assumptions 

1 .  The  station  is  to  be  capable  of  adding  or  replacing  “components”.  To  support  this  the  user 
interface  will  need  to  have  a  mechanism  to  “add”  a  new  component  with  a  date  lot  sequence 
code. 

2.  Should  this  station  be  considered  part  of  the  route?  It  is  assumed  yes,  and  that  we  have 
100%  inspection. 

3.  It  is  assumed  that  the  current  Real  Time  Feedback  System  will  be  used,  with  the  possible 
enhancement  of  hitting  the  relational  database.  In  addition,  the  system  to  roll  up  all  the 
defects  data  into  the  RDBMS  for  long  term  trending  and  capability  analysis. 

2.12  Board  Label  Application  Station 

2.12.1  Overview 

The  Board  Label  Application  Station  is  where  an  operator  generates  Polyester  labels  that  are 
applied  to  the  individual  Circuit  Boards  that  make  up  a  PWA.  These  labels  are  used  for  tracking 
after  the  Depanel  operation. 

The  station  consists  of  the  following: 

•  A  WCC  PC  that  interacts  with  the  plant  wide  FCS  system  and  the  operator. 

•  A  Bar  Code  Printer  capable  of  printing  Polyester  Labels  for  Circuit  Boards.  The  interface 
between  the  WCC  PC  and  the  Printer  is  RS232  communications. 
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2.12.2  Operating  Scenario 

1 .  The  operator  will  print  the  appropriate  number  of  Circuit  Board  labels. 

2.  The  User  Interface  screen  shall  support  password  protection  so  that  only  authorized 
operators  may  create  the  labels.  Units  are  sequenced  automatically  by  the  Cell  based  on 
previous  serial  numbers.  These  numbers  are  to  be  Julian  Date  and  Serial  Number  based  along 
with  a  Product  Identifier. 

3.  Once  the  labels  are  defined,  the  WCC  PC  shall  print  the  labels  for  the  operator  to  place  on 
the  Circuit  Board.  If  the  operator  needs  to  print  additional  labels  due  to  spoilage,  they  will 
be  able  to  "re-print"  them  with  the  proper  password. 


2.12.3  Issues  /  Assumptions 

1 .  Verification  of  the  bar  code  labels  printed  will  be  performed  on  a  continuos  basis. 

2.  This  station  may  be  combined  with  the  previous  Inspection  /  Touch  Up  Station. 

2.13  Wash  (Westkleen)  Station 
2.13.1  Overview 

The  Wash  Station  provides  the  aqueous  cleaning  necessary  to  remove  the  residue  that  is  a  result  of 
the  solder  paste  curing  process. 

This  station  consists  of  the  following: 
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•  Westkleen  PWA  Wash  Machine  capable  of  Manual  Program  Select  and  Run.  The  interface 
supported  by  this  station  is  "proprietary"  and  using  ACK/NAK  handshake  with  checksum. 

•  PLC  Commmiications  using  SMEMA  interface  and  direct  I/O  to  the  Westkleen  Controller. 

•  A  WCC  PC  that  interacts  with  the  plant  wide  system  and  PLC. 

•  A  BCR  that  is  positioned  at  the  entry  of  the  Cell  with  stop  capability  to  provide  WIP 
functionality  and  support. 
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2.13.2  Operating  Scenario 

1 .  Same  basic  set  of  operating  scenario  as  the  earlier  sections.  Changeover  data  from  the 
database  includes: 

•  Program  Name  only. 

2.14  Issues  /  Assumptions 

1 .  Is  there  a  real  need  to  have  multiple  recipes  with  this  station.  In  most  cases  one  should  be 
able  to  use  only  a  single  recipe  and  not  need  changeover.  Recommendation  is  that  no 
interface  be  designed  for  this  as  in  most  cases  only  one  recipe  will  be  necessary. 

2.15  PWA  Depanel  Station 
2.15.1  Overview 

The  PWA  Depanel  Station  is  used  to  remove  the  individual  circuit  cards  that  ride  in  a  panel  chassis. 
The  individual  cards  are  held  to  the  panel  by  tabs  that  are  left  in  place  as  part  of  the  panel  creation. 
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When  these  tabs  are  machined  out,  the  individual  circuit  cards  are  separated  and  the  Kapton  labels 
are  added  to  the  individual  cards. 

The  station  consists  of  the  following: 

•  CENCORP  TR4000  Milling  Machine.  The  interface  supported  by  this  station  is 
"proprietary" 

•  PLC  Communications  using  SMEMA  interface  and  direct  I/O  to  the  CENCORP  Controller. 

•  A  WCC  PC  that  interacts  with  the  plant  wide  PCS  system  and  PLC. 

•  A  BCR  that  is  positioned  at  the  entry  of  the  Cell  with  stop  capability  to  provide  WIP 
functionality  and  support. 
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2.15.2  Operating  Scenario 

1 .  Same  basic  set  of  operating  scenario  as  the  earlier  sections.  Changeover  data  from  the 
database  includes: 

•  Program  Name 

•  Depanel  Fixture 

2.  The  operator  then  depanels  the  circuit  cards  out  of  the  panel. 

2.15.3  Issues  /  Assumptions 

1 .  Do  we  want  to  consider  total  manual  fixture  changeover  or  do  we  want  to  investigate 
automatic  fixture  changeover?  The  assumption  is  that  this  will  be  a  manual  changeover  for 
MPCL  PWAs. 
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2.16  In-Circuit  (GENRAD)  Station 


2.16.1  Overview 

The  In-Circuit  Station  provides  the  electrical  tests  needed  to  verity  that  the  individual  circuits  are 
good  and  that  there  are  no  solder  related  problems  that  could  cause  electrical  malfunction.  If  a  PWA 
unit  fails  the  test,  it  is  manually  routed  to  a  "rework"  area  for  rework  and  repair.  The  fail  data 
collected  on  the  unit  is  provided  to  the  diagnostic  technician  to  isolate  the  problem  and  correct  it. 

The  station  consists  of  the  following: 

•  GENRAD  In-Circuit  Fixture  Handling  Station.  The  interface  supported  by  this  station  is 
"proprietary"  and  using  ACK/NAK  handshake  with  checksum.  Other  details  are  unknown. 

•  GENRAD  In-Circuit  Test  Computer.  Interface  to  the  Test  Data  collection  is  place  and  uses 
RS232. 

•  PLC  Communications  using  SMEMA  interface  and  direct  I/O  to  the  GENRAD  Controller. 

•  A  WCC  PC  that  interacts  with  the  plant  wide  FCS  system  and  PLC. 

•  A  hand  held  BCR  with  stop  capability  to  provide  WIP  functionality  and  support. 


PASS 


2.16.2  Operating  Scenario 

1 .  Same  basic  set  of  operating  scenario  as  the  earlier  sections.  Changeover  data  from  the 
database  includes: 

•  Program  Name 

•  In-Circuit  Test  Fixture 
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2.  The  in-circuit  tester  performs  the  test  on  the  PWAs  and  when  it  is  done  with  the  assembly, 
it  will  alert  the  operator  that  the  test  passed  and  further  processing  can  continue.  If  the  PWA 
failed,  it  will  alert  the  operator  that  the  test  "FAILED"  using  the  PC  cell  controller  and  ask 
for  the  PWA  to  be  removed  for  rework. 

2.16.3  Issues  /  Assumptions 

1 .  Are  we  to  perform  any  data  collection  from  the  test  station.  If  yes,  is  this  data  to  be  only 
fail  data  or  all  data?  How  do  we  want  to  handle  detail  test  step  value  and  test  limits?  For 
the  purpose  of  MPCL,  we  are  to  only  collect  status;  test  data  will  be  collected  as  done 
currently. 

2.  The  assumption  is  that  this  will  be  a  manual  changeover. 

3.  What  level  of  test  data  collection  will  be  made  available  to  the  rework  test  technician  on  line? 
Is  this  real-time?  The  assumption  is  yes  to  both  based  on  the  existing/planned  test  data 
collection  automation  that  is  being  done  outside  of  the  MPCL  Program.  No  additional  work 
is  being  proposed  as  part  of  MPCL. 

2.17  Core  Bond  Station 
2.17.1  Overview 

The  Core  Bond  Station  is  a  manual  assembly  station.  In  this  station  an  operator  taken  two  PWA’s 
and  bonds  them  over  a  heat  sink,  back  to  back.  This  results  in  one  assembly  being  formed  from  two 
PWA. 

The  station  consists  of  the  following: 

•  A  WCC  PC  that  interacts  with  the  plant  wide  FCS  system  and  operator. 

•  A  hand  held  BCR  to  provide  WIP  functionality  and  support. 
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2.17.2  Operating  Scenario 

1 .  The  Operator  picks  up  the  PWAs  and  scans  the  bar  code.  The  system  will  perform  all  the 
WIP  checks  that  it  would  normally  do  for  a  PWA  on  the  line.  Any  exception  condition  will 
be  brought  to  the  operators  attention. 

2.  If  the  PWA  status  is  OK,  the  operator  will  than  core  bond  the  two  PWAs  and  enter  the  data 
into  the  system  through  the  user  interface  provided.  This  station  will  provide  the  necessary 
user  interaction  to  have  one  PWA  become  the  “parent”  assembly,  while  the  second  one 
becomes  the  “child”  assembly. 

3.  Using  this  interface  the  operator  will  have  to  option  of  seeing  work  instructions  for  how  to 
perform  the  assembly. 

2.17.3  Issues  /  Assumptions 

1 .  The  station  is  to  be  capable  of  creating  a  higher  level  assembly  and  a  child  assembly  from 
two  PWA’s.  To  support  this  the  user  interface  will  need  to  have  a  mechanism  to  “mate”  the 
two  PWA’s  together.  From  here  on  down,  the  “parent”  PWA  will  only  need  to  be  WIPed, 
and  all  the  data  is  for  that  PWA.  The  child  PWA  goes  along  for  the  ride. 

2.18  Hot  Bar  Station 
2.18.1  Overview 

The  Hot  Bar  Station  is  a  manual  solder  assembly  station.  In  this  station  an  operator  taken  two 
PWA’s  that  are  assembled  and  solders  one  end  with  a  connector  for  the  preparation  of  the  flex  cable 
attachment. 
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The  station  consists  of  the  following: 

•  A  WCC  PC  that  interacts  with  the  plant  wide  PCS  system  and  operator. 

•  A  hand  held  BCR  to  provide  WIP  functionality  and  support. 
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2.18.2  Operating  Scenario 

1 .  The  Operator  picks  up  the  PWA  and  scans  the  bar  code  of  the  “parent”  PWA.  The  system 
will  perform  all  the  WIP  checks  that  it  would  normally  do  for  a  PWA  on  the  line.  Any 
exception  condition  will  be  brought  to  the  operators  attention. 

2.  If  the  PWA  status  is  OK,  the  operator  will  then  hot  bar  the  connector  in  preparation  for  the 
flex  cable. 

3.  Using  this  interface  the  operator  will  have  the  option  of  viewing  work  instructions  for 
performing  the  assembly. 

2.18.3  Issues  /  Assumptions 

The  station  should  be  capable  of  determining  the  correct  WIPed  PWA,  if  the 
child  is  Wiped  instead  of  the  “parent”.  This  will  simplify  the  users  job  of 
wanding  either  of  the  serial  numbers. 
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2.19  Flex  Attach  Station 


2.19.1  Overview 

The  Flex  Attach  Station  is  a  manual  cable  assembly  station.  In  this  station  an  operator  taken  two 
PWA’s  that  are  assembled  together  and  attaches  the  flex  cable  assembly  to  them. 

The  station  consists  of  the  following: 

•  A  WCC  PC  that  interacts  with  the  plant  wide  FCS  system  and  operator. 

•  A  hand  held  BCR  to  provide  WIP  functionality  and  support. 
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2.19.2  Operating  Scenario 

1 .  The  Operator  picks  up  the  PWA  and  scans  the  bar  code  of  the  “parent”  PWA.  The  system 
will  perform  all  the  WIP  checks  that  it  would  normally  do  for  a  PWA  on  the  line.  Any 
exception  condition  will  be  brought  to  the  operators  attention. 

2.  If  the  PWA  status  is  OK  with  both  the  PWA’s,  the  operator  will  than  attach  the  flex  cable. 

3 .  Using  this  interface  the  operator  will  have  to  option  of  seeing  work  instructions  for  how  to 
perform  the  assembly. 

2.19.3  Issues  /  Assumptions 

1 .  The  station  should  be  capable  of  determining  the  correct  WIPed  PWA,  if  the;  child  is  WIPed 
instead  of  the  “parent”.  This  will  simplify  the  users  job  of  wanding  either  of  the  serial 
numbers. 
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2.20  Inspection  /  Touch-Up  Station 


2.20.1  Overview 

The  Inspection  /  Touch-Up  Station  is  a  manual  inspection  and  rev^ork  station.  At  this  station  an 
operator  inspects  the  PWA’s  for  defects  such  as  the  quality  of  assembly  of  the  Core  Bond,  Hot  Bar 
and  the  Flex  Attachment  processes.  Defects  are  noted  into  the  defects  database  using  a  graphical 
interface,  and  the  appropriate  touch  up  is  done.  Depending  on  the  throughput,  there  may  be  more 
than  one  station  performing  this  operation.  Details  of  this  station  type  are  discussed  in  section  4.10 
above. 

2.21  Repair  Station 

2.21.1  Overview 

The  Repair  Station  provides  the  diagnosis  and  rework  for  all  PWA’s  that  failed  the  in-circuit  test  as 
well  as  any  inspection  identified  defects  from  the  manual  assembly.  The  test  failure  or  defects  data 
collected  on  the  unit  is  provided  to  the  diagnostic  technician  to  isolate  the  problem  and  correct  it. 
This  data  may  be  on  paper  or  available  electronically.  This  repair  station  will  be  in  a  common  area, 
and  not  be  part  of  a  “line”. 

The  station  consists  of  the  following; 

•  A  WCC  PC  that  interacts  with  the  plant  wide  FCS  system  and  operator. 

•  A  hand  held  BCR  to  provide  WIP  functionality  and  support. 
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2.21.2  Operating  Scenario 
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1 .  The  station  should  be  capable  of  determining  the  correct  WIPed  PWA,  if  the;  child  is  WIPed 
instead  of  the  “parent”.  This  will  simplify  the  users  job  of  wanding  either  of  the  serial 
numbers. 

2.  The  operator  will  bring  up  the  test  /  diagnostic  data  for  the  PWA  and  perform  all  the 
necessary  rework  to  it. 

3.  Using  this  interface  the  operator  will  have  to  option  of  viewing,  storing  or  printing  the  trend 
and  pareto  charts  of  test  results. 

4.  At  the  rework  station  the  test  technician  shall  diagnose  the  problem  and  provide  the 
necessary  corrective  action  to  fix  the  problem.  They  will  then  route  the  PWA  back  to  the 
sending  station  for  retest. 

2.21.3  Issues  /  Assumptions 

1 .  At  this  station  the  operator  shall  have  the  capability  to  add  or  replace  “components”.  To 
support  this,  the  user  interface  will  need  to  have  a  mechanism  to  “add”  a  new  component 
with  a  date  lot  sequence  code. 

2.  The  existing  method  of  trend  reporting  will  be  extended  to  provide  for  real  time  feedback  of 
paretos,  trending,  etc. 


2.22  Conformal  Coat  Station 
2.22.1  Overview 

The  Conformal  Coat  process  consists  of  putting  a  fine  layer  of  an  acrylic  or  varnish  based  coating 
that  cures  either  through  heat  or  UV  light.  This  coating  protects  the  circuit  from  foreign  growth  and 
protection  from  moisture  and  other  electrical  containment's. 

The  station  consists  of  the  following: 

•  “ITI”  Conformal  Coat  Station.  The  interface  supported  by  this  station  is  "proprietary”. 

•  PLC  Communications  using  SMEMA  interface  and  direct  I/O  to  the  Conformal  Coat 
Controller. 

•  A  WCC  PC  that  interacts  with  the  plant  wide  PCS  system  and  PLC. 

•  A  BCR  to  provide  WIP  functionality  and  support. 
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2.22.2  Operating  Scenario 

1 .  Same  basic  set  of  operating  scenario  as  the  earlier  sections.  Changeover  data  from  the 
database  includes: 

•  Program  Name 

•  Coating  substance  if  different 

2.22.3  Issues  /  Assumptions 

1 .  Is  there  a  real  need  to  have  multiple  recipes  with  this  station.  In  most  cases  one  should  be 
able  to  use  only  a  single  recipe  and  not  need  changeover.  Same  recommendation  as  cleaner. 

2.23  Final  Assembly  Station 
2.23.1  Overview 

The  Final  Assembly  process  consists  of  putting  the  final  mechanical  packaging  around  the  P  WA  to 
make  it  a  complete  unit.  This  typically  consists  of  fastening  hardware  and  some  shell  that  wraps 
around  the  PWA  (  if  applicable). 

The  station  consists  of  the  following: 

•  Manual  Station  where  final  assembly  takes  place  using  hand  tools  and  work  instructions  as 
to  what  is  needed  to  put  the  PWA  into  a  final  assembly. 

•  A  WCC  PC  that  communicates  with  the  plant  wide  FCS  system  and  the  operator. 
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A  BCR  to  provide  WIP  functionality  and  support. 
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2.23.2  Operating  Scenario 

1 .  The  Operator  picks  up  the  PWA  and  scans  the  barcode.  The  PC  performs  a  validation 
check  on  WIP  and  other  aspects  of  the  unit  such  as  all  the  tests  are  completed,  that  there  are 
no  outstanding  issues  against  the  unit  and  that  it  is  ready  for  final  assembly. 

2.  The  PC  then  brings  up  the  appropriate  work  instructions  as  how  to  assembly  the  PWA  into 
a  final  assembly  with  call  outs  for  all  appropriate  tooling  and  part  lists  needed  at  this 
operation. 

3.  After  the  unit  is  completed  the  Operator  will  “finish”  the  assembly  and  WIP  Out  the  unit. 

2.23.3  Issues  /  Assumptions 

1 .  The  station  should  be  capable  of  determining  the  correct  WIPed  PWA,  if  the  child  is  WIPed 
instead  of  the  “parent”.  This  will  simplify  the  users  job  of  wanding  either  of  the  serial 
numbers. 

2.  The  work  instructions  are  to  be  graphical  and  /  or  textual. 

2.24  Pack  and  Ship  Station 

2.24.1  Overview 

The  Pack  and  Ship  Station  consists  of  the  following: 


64 


•  Manual  Station  where  Packing  and  Shipping  takes  place  using  normal  packing  and  shipping 
materials. 

.  Instructions  describing  what  to  pack  into  what  boxes  and  how. 

.  A  WCC  PC  that  interacts  with  the  plant  wide  PCS  system  and  operator. 

•  Bar  Code  Printer  to  print  packing  labels  for  either  individual  or  multi-unit  boxes. 
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2.24.2  Operating  Scenario 

1 .  The  Operator  picks  up  the  PWA  and  scans  the  barcode.  The  WCC  PC  performs  a  complete 
validation  check  on  WIP,  Defects  /  Test  and  Bill  of  Material  History  to  determine  if  the  unit 
has  completed  all  necessary  steps  in  the  production  process  prior  to  this  point.  It  will  also 
determine  if  there  are  no  outstanding  issues  against  this  unit  or  for  the  work  order  that  it 
belongs  to. 

2.  The  WCC  PC  brings  up  the  appropriate  work  instructions  for  packing  the  final  assembly 
with  call  outs  for  all  appropriate  boxes,  bar  code  printouts  etc.  needed  at  this  operation. 

3.  After  the  unit  is  completed  the  Operator  will  “finish”  the  assembly.  The  system  will  close 
out  the  unit  and  put  it  in  finished  goods  inventory.  The  system  shall  also  roll  up  transient 
data  for  that  unit  into  summary  tables  so  that  the  server  database  is  self  maintaining. 

2.24.3  Issues  /  Assumptions 

1 .  1 00%  “auditing”  is  required  to  validate  that  the  Unit  has  completed  its  route  and  that  there 
are  no  outstanding  items  left  for  this  unit  to  complete  prior  to  shipping. 
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2.  The  Shipping  /  Receiving  System  shall  determine  how  the  unit  is  packed,  what  boxes  it 
should  go  into  and  where  it  should  be  shipped  to.  This  is  outside  of  the  scope  of  the  CIM 
portion  of  the  line? 

3.  “Palletizing”  function  is  to  be  supported  outside  of  the  CIM  System. 
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Appendix  3  -  CIM  System  Design  Description 

3.  CIM  System  Design  Description 

The  method  used  in  documenting  the  design  process  includes  providing  a  high  level  design 
description  of  each  of  the  sub-subsystem  along  with  a  modular  “sub-system  dataflow”  diagram  that 
delineates  the  type  and  level  of  support  expected  from  each  module  within  a  sub-system.  These 
modules,  and  their  respective  functions  are  defined  in  Figure  3-1  below. 


Legend  for  Dataflows 
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Figure  3-1. 
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In  addition,  included  are  the  major  “user  based  dataflows”  that  represent  how  these  modules  are  to 
be  used  to  meet  the  requirements  deliverables.  These  modules  include  Generic  User  Forms  that  can 
run  on  any  user  station.  User  Screens  at  Machine  Stations  that  are  specific  to  a  particular  or  class  of 
machine,  Functional  Modules  that  perform  some  processing  activity  that  needs  to  be  specifically 
addressed  in  the  distributed  architecture,  Database  Tables  that  provide  the  repository  for  the  CIM 
Data  and  Reports  that  can  be  viewed  on  line,  printed  or  written  to  a  file  for  review  or  used  by  an 
external  systems. 

The  CIM  System  Design  description  is  separated  into  Factory  Control  System  (FCS)  sub-systems 
and  Work  Cell  Controller  (WCC)  sub-systems.  In  general  WCC  sub-systems  receive  their 
configuration  and  reporting  support  from  the  FCS,  but  the  main  transaction  load  is  on  the  WCC 
level. 

The  following  are  the  FCS  sub-systems: 

•  Factory  System  Configuration  (FCS) 

•  Bill  of  Materials  (BOM) 

•  Configuration  Management  (CM) 

•  Quality  Model  (QM) 

•  Repetitive  Scheduling  /  Work  Order  Management  (WOM) 

•  Production  Reporting  (PR) 

•  Archive  /  Dearchive  (ARC) 

The  following  are  WCC  sub-systems: 

•  Work  In  Process  (WIP) 

•  Production  Changeover  (PCO) 

•  As  Build  Traceability  (ABT) 

•  Alarm  Management  (AM) 

The  detail  design  discussion  for  each  of  the  sub-systems  is  given  below,  while  the  major  user  based 
dataflows  are  discussed  in  Appendix  4. 

3.1  Factory  System  Configuration  (FSC)  Design  Description 

The  main  function  of  the  FSC  sub-system  is  to  provide  basic  plant  configuration  data  to  set  up  the 
factory.  Prior  to  any  production  activity  or  development  of  product  build  definitions,  the  base 
CIM  System  had  to  be  identified.  FSC  provides  this  through  user  forms  that  support  the 
maintenance  of  plant  tables,  user  authorization,  factory  operations,  manufacturing  locations  and  slot 
to  machine  relationships.  These  are  discussed  in  detail  in  the  RS  document. 

The  major  design  goals  include: 
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•  FSC  shall  define  the  operation  types,  operation  descriptions,  and  their  relationship.  For 
example.  Operation  1 10  is  of  Operation  Type  Top  Side  Surface  Mount. 

•  FSC  shall  define  manufacturing  locations  of  production  equipment  and  stations  and  their 
relationships  to  operations.  For  example,  Mfg.  Location  Panasonic  MV-II-1  is  of  Operations 

no. 

•  FSC  shall  define  slot  locations  and  their  relationships  to  manufacturing  locations.  For  example, 
MV-II-1  has  100  slots  numbered  MV-II-1 -001  to  MV-II-1 -100. 

•  FSC  shall  provide  the  capability  to  maintain  user  password  and  relationships  among  users,  user 
groups,  and  user  qualifications.  For  example.  User  John  Doe  belongs  to  group 

Line  1  Shift  1  Group  and  has  authorization  to  only  perform  Operation  110. 

Figure  3-2  below  is  the  dataflow  diagram  which  shows  major  design  modules  for  this  sub¬ 
system. 
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3.2  Bill  Of  Material  (BOM)  Design  Description 

The  main  function  of  the  BOM  sub-system  is  to  provide  all  the  necessary  BOM  information  along 
with  product  and  process  related  data  to  support  the  manufacturing  process.  In  this  regard,  the 
BOM  sub-system  supports  the  maintenance  of  the  Manufacturing  BOM  (MBOM)  which  is 
derived  from  the  Engineering  BOM  (EBOM),  the  quick  generation  of  part  list  substitution,  and  the 
interface  to  Product  Data  Management  (PDM)  system  and  Material  Management  System  (MMS). 
To  achieve  this  a  number  of  functional  elements  have  to  be  made  available.  These  are  discussed  in 
detail  in  the  RS  document. 

The  major  design  goals  include: 
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•  BOM  shall  maintain  single  level  product  structure  for  both  EBOM  and  MBOM. 

•  BOM  shall  provide  the  capability  to  quickly  generate  new  revisions  of  a  parts  list  to  run  a 
substitute  part  when  the  planned  part  is  not  available. 

•  BOM  shall  support  the  interface  to  download  an  EBOM  from  the  PDM  system  and  validate 
parts  against  the  Item  Master  provided  by  MMS. 

•  BOM  shall  support  the  interface  to  download  the  Item  Master  from  MMS  and  access  the 
MMS  feeder  /  bin  locations. 

•  BOM  shall  support  on-line  viewing  of  the  MBOM  and  allow  modification  by  authorized 
personnel. 

•  BOM  shall  provide  a  set  of  reports  to  provide  single  or  multi  level  details  of  product  and  part 
usage  by  product  and  location. 

Figure  3-3  is  the  dataflow  diagram  which  shows  major  design  elements  for  this  sub-system. 
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Figure  3-3. 

3.3  Configuration  Management  (CM)  Design  Description 
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The  main  function  of  the  CM  sub-system  is  to  manage  the  product  configuration  by  part  number, 
drawing,  parts  list  and  manufacturing  revisions.  In  this  regard,  CM  supports  the  maintenance  of  all 
appropriate  revisions,  the  maintenance  of  the  build  effectivity,  and  validation  of  product 
configuration.  Figure  3-4  is  the  dataflow  diagram  which  shows  major  design 
elements  for  this  sub-system.  To  achieve  this  a  number  of  functional  elements  have  to  be 
made  available.  These  are  discussed  in  detail  in  the  RS  document. 
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Figure  3-4. 


The  major  design  goals  include: 

•  CM  shall  maintain  all  engineering  and  manufacturing  revisions  for  the  product  and  support 
modifications  from  authorized  CM  personnel. 

•  CM  shall  maintain  build  effectivity  based  quantity,  date  range  or  serial  number  range  and 
support  build  status  modification. 
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•  CM  shall  maintain  the  process  programs,  instructions,  etc.  configuration  by  manufacturing 
revision  and  validate  the  status  to  be  “production”  before  allowing  them  to  be  used  for 
production. 

•  CM  shall  validate  the  repetitive  schedule  or  manufacturing  order  generated  by  the  PCS  system 
against  the  build  effectivity  and  status  prior  to  releasing  the  order. 

•  CM  shall  define  standard  routing  and  optional  routings  for  every  product. 

•  CM  shall  provide  a  set  of  reports  to  provide  the  status  and  files  or 
programs  locations  with  appropriate  revisions  for  a  given  product. 


3.4  Quality  Model  (QM)  Design  Description 

The  main  fimction  of  the  QM  sub-system  is  to  allow  new  designs  to  be  rated  for  their  quality 
potential.  Figure  3-5  is  the  dataflow  diagram  which  shows  major  design 
elements  for  this  sub-system.  In  this  regard,  QM  uses  the  supplier,  process  quality  along 
with  process  verification 
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Figure  3-5. 

effectiveness  as  input  to  compute  the  quality  potential  of  the  product.  To  achieve  this  a  number  of 
functional  elements  have  to  be  made  available. 


72 


The  major  design  goals  include: 

•  QM  shall  maintain  parts-per-million  (PPM)  values  for  processes  and  supplier  parts  and  history 
for  PPM  changes. 

•  QM  shall  maintain  process  verification  effectiveness  and  history  for  effectiveness  changes. 

•  QM  shall  compute  and  display  the  results  of  the  product  PPM  based  on  PPM  inputs  of 
supplier  parts,  processes,  and  verification  effectiveness. 

•  QM  shall  provide  a  set  of  reports  to  provide  the  results  of  the  quality 
model  PPM  for  the  product. 

3.5  Repetitive  Scheduling  /  Work  Order  Management  (WOM)  Design  Description 

The  main  function  of  the  WOM  sub-system  is  to  manage  the  building  of  product  to  the  schedule  or 

order  for  a  selected  product  configuration.  Figure  3-6  is  the  dataflow  diagram  which  shows  major 
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Management  (WOM)  Dataflow 


Figure  3-6. 

design  elements  for  this  sub-system.  To  achieve  this  a  number  of  functional  elements  have  to  be 
made  available.  These  are  discussed  in  detail  in  the  MPCL  CIM  Requirements  document. 

The  major  design  goals  include: 


WOM  shall  provide  the  capability  to  create  a  new  schedule  and  validate  that  the  schedule  can  be 
built. 


•  WOM  shall  also  validate  the  schedule  against  the  configuration  effectivity  and  flag  any 
discrepancies  to  the  planner. 

•  WOM  shall  provide  reports  for  complete  status  on  the  schedule,  such  as 

units  started,  completed  and  in-process. 

3.6  Production  Reporting  (PR)  Design  Description 

The  main  function  of  the  PR  sub-system  is  to  provide  a  number  of  “standard”  reports  to  support 
management  of  the  production  process.  In  this  regard,  PR  supports  “shift”  configuration  and 
maintenance,  reports  of  production  yields,  work  in  process  (WIP),  and  production  cycle  time.  To 
achieve  this  a  number  of  functional  elements  have  to  be  made  available.  These  are  discussed  in  detail 
in  the  RS  document.  Figure  3-7  above  is  the  dataflow  diagram  which  shows  major  design  elements 
for  this  sub-system. 

The  major  design  goals  include: 

•  PR  shall  define  and  configure  “shifts”  and  Usergroups  operations  associated  with  each  “shift”. 

•  PR  shall  support  the  capability  to  send  “shift”  change  event  notice  to  any  station  on  the  route. 

•  PR  shall  provide  WIP  reports  that  show  the  total  number  of  WIP  transactions  performed  during 
each  shift. 

•  PR  shall  provide  Production  Yield  reports  that  show  yield,  scrap,  rejects,  etc.  at  each  station  by 
shift. 

•  PR  shall  provide  Production  Cycle  Time  reports  that  show  average,  high,  low  and  downtime, 
blocked  time  for  each  of  the  operations  and  products  of  the  shift. 

•  PR  shall  provide  the  capability  to  view  the  complete  history  of  any  assembly  at  any  station. 
History  information  such  as  defective  components,  repairs  made,  and  test  results  for  the 
assembly  shall  be  included. 

•  PR  shall  support  the  archiving  of  shift  data  that  can  later  be  de-archived  for  analysis  in  a 
relational  database. 
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Figure  3-7. 

3.7  Archive  /  Dearchive  (ARC)  Design  Description 

The  main  function  of  the  Archive  /  Dearchive  (ARC)  Sub-System  is  to  provide  the  capability  of 
archiving  and  dearchiving  all  the  relevant  system  data.  In  this  regard,  ARC  supports  the  archiving 
and  dearchiving  of  WIP,  Trace,  Product,  Factory  and  Event  data  for  review  and  analysis  using  a 
relational  database.  In  addition,  the  capability  to  clear  the  data  from  the  line  database  is  essential. 

To  achieve  this  a  number  of  functional  elements  have  to  be  made  available.  These  are  discussed  in 
detail  in  the  RS  document  and  appendix. 

The  major  design  goals  include: 

•  ARC  shall  support  the  self  maintenance  of  WIP,  Trace,  and  Event  Data  from  the  Line  Databases 
when  the  imit  being  produced  has  been  completed  or  shipped. 

•  ARC  shall  provide  the  capability  to  archive  all  unit  (WIP,  Trace  and  Event),  product  and 
factory  data  at  regular  interval  with  the  capability  to  identify  that  this  data  has  been  archived. 


•  ARC  shall  support  the  archiving  of  data  in  a  compressed  format  that  can  be  later  be 
decompressed  and  analyzed  in  a  relational  database. 

•  ARC  shall  provide  dearchiving  capability,  without  requiring  that  the  dearchiving  be  done  into  the 
same  structure  tables  as  the  original. 

•  ARC  shall  provide  complementary  sets  of  reports  to  provide  the  status  and  location  of  all 
archived  data. 

Figure  3-8  is  the  dataflow  diagram  which  shows  major  design  elements  for  this  sub-system. 
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3.8  Work  In  Process  (WIP)  Design  Description 

The  main  function  of  the  Work  In  Process  (WIP)  Sub-System  is  to  provide  the  capability  to  validate 
that  every  unit  manufactured  goes  through  its  prescribed  route.  In  this  regard,  WIP  supports  the 
control  and  tracking  of  PWA  units  on  the  route.  To  achieve  this  a  number  of  functional  elements 
have  to  be  made  available.  These  are  discussed  in  detail  in  the  RS  document. 


The  major  design  goals  include: 


•  WIP  shall  verify  that  the  unit  is  at  the  correct  location  based  on  its  route. 

•  WIP  shall  determine  that  the  unit  in  not  in  a  “hold”  condition. 
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•  WIP  shall  provide  the  capability  to  "transfer"  a  imit  from  its  "base"  route  to  an  "alternate"  route 
(i.e.:  a  special  “repair”  function  or  engineering  evaluation). 

•  WIP  shall  provide  a  function  that  will  place  a  unit  or  range  of  units  on  “hold”. 

•  WIP  shall  support  an  authorized  person  to  change  the  Status  or  Location  of  a  Unit. 

•  WIP  shall  support  the  reporting  of  unit  history  with  time,  station  and  user  data. 
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3.9  Product  Change  Over  (PCO)  Design  Description 

The  main  function  of  the  Product  Changeover  (PCO)  Sub-System  is  to  provide  the  capability  to 
simplify  and/or  automate  the  changeover  of  part  programs,  component  parts,  fixtures  and  any 
instructions  needed  to  build  a  new  product  at  a  station  different  from  the  one  currently  being 
produced.  In  this  regard,  PCO  supports  the  status  and  the  control  of  Station  Configuration.  To 


achieve  this  a  number  of  functional  elements  have  to  be  made  available.  These  are  discussed  in  detail 
in  the  RS  document. 

The  major  design  goals  include: 

•  PCO  shall  verify  if  changeover  is  needed  for  any  product  entering  the  cell  that  is  different  than 
the  previous  one. 

•  PCO  provide  advance  notification  to  downstream  stations  that  a  new  product  has  been 
introduced  upstream. 

•  PCO  shall  support  operator  to  determine  the  difference  in  component  parts,  feeders,  fixtures 
and  instructions  for  a  new  product. 

•  PCO  shall  provide  features  to  validate  that  a  product  changeover  is  successful.  This  may 
include  automatic  part  program  download  ( or  operator  prompted  download),  verification  of 
parts  in  appropriate  feeders  and  slots,  and  a  checklist  of  manual  changes. 

•  PCO  shall  provide  for  feeder  data  to  be  extracted  from  part  programs. 

•  PCO  shall  provide  for  on-line  storage  areas  to  be  monitored  by  a  material  management  system 
for  automatic  part  replenishment. 

•  PCO  shall  provide  a  complete  set  of  forms  and  a  graphical  user  interface  for  performing 
changeover  at  a  manual  station. 

•  PCO  shall  support  the  maintenance  of  the  next  serial  number. 

•  PCO  shall  provide  complementary  sets  of  reports  to  verify  the  setup  of  each  and  every  station 
that  a  product  is  to  travel  to. 

Figure  3-10  is  the  dataflow  diagram  which  shows  major  design  elements  for  this  sub-system. 

3.10  As  Built  Traceability  (ABT)  Design  Description 

The  main  function  of  the  As  Built  Traceability  (ABT)  Sub-System  is  to  provide  the  capability  to 
track  all  component  parts  along  with  their  sequence  codes  or  serial  number  down  to  the  lowest 
manufactured  level.  In  this  regard,  ABT  supports  the  collection  and  reporting  of  the  complete  as 
built  product  structure.  In  addition,  it  also  provides  for  the  capability  that  in  the  event  a  certain 
sequence  code  of  a  component  part  has  been  deemed  prone  to  failure  and  requires  further  action, 
ABT  shall  support  identifying  all  products  along  with  their  unique  serial  number  that  have  it.  To 
achieve  this,  a  number  of  functional  elements  have  to  be  made  available.  These  are  discussed  in 
detail  in  the  RS  document. 
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Product  Change  Over  (PCO)  Dataflow 


Maintain  Changeover 

Mfg  Instruction 

Configuration 

Maintenance 

User:  Process  Eng. 

User:  Process  Eng. 

«RS-3.2.3» 

«RS-3.2.3» 

*  Provide  tools  and  forms 

*  Provide  access  to 

to  maintain  changeover 

maintain  Mfg  instiuction 

and  setup  Tabes. 

Tabes. 

*Also  Maintain  RIP 

*  Change  and  update  M^ 

Configuration  and  Sot 
Location  Relationships. 

instructions  ant  locations. 

Station  Changeover  / 
Feeder  Activation 
User  Operator 
«RS.3.2.3» 

*  Support  Changecver 
Validation  for  Station 
Fe  ede  re  and  Instiu  ctions . 


Manual  Station 
Changeover 
Usen  Operator 
«RS4i.3» 

*  Si^port  Changeover 
Activation  for  Manual 
Station. 


Manual  Station 
User:  Operator 
«RS-3.2.3» 
«>S-3.1». 

*  Changeover  Request 

*  Advance  Notification. 

*  Manual  Station 
Changeover. 


Autoniated  Staton 
User:  Operator 
«RS-6.2.1» 
«OS-3.1». 

•  Changeover  Requests. 

•  Advance  Notification. 

•  Execute  Changeover. 


First  Changeover 
Station 

User:  Supervisor 
«OS-l1». 

*  Provides  Supervisory 
Validation  with  password. 


MMS  Interface  for  Daily 
Bin  Use 
Function 
«DN^> 

I  Usage  of  Line  Side  Storage 
based  on  daily  planned  build. 


Advance  Notification 
Function 
«RS-6.1^ 

•  Reviews  Route  Tabes  and 
sends  notifications  to 
downstream  stations . 


"tel 


Execute  Changeover 
Function 
«RS-3.2.3» 

I  •  Receives  changeover 
{ notices  from  stations. 

Update  Tabes  based  on 
I  changeover  request. 
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Changeover  Request 
Function 
«RS-3.2.3» 

*  Provides  data  for  product 
changeover  forany  station. 

'  Validates  feeder  and  setup 
data  on  station. 


TIMMS  Interface  for 
Feeder  Data 
Fun  ction 
«RS-4.8» 

•  Provides  feeder  data  far 
product  from  TIMMS 
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I  Maintain  Serial  Number 
User  Supervisor 
«DN.7» 

*  Maintain  Next  Serial 

I  Valid  Serial  Number  for 
Products. 


Station  Setup  Report 
User:  Process  Eng. 
«RS-3.5.1» 

•  Required  Parts  at  Feeders. 

*  Exceptions  based  on  cirrent  setup. 


Planned  Setup  Report 
User:  Process  Eng. 
«DN-6» 

*  All  Setup  Data  by  Prodxt. 

*  All  Setup  Data  Station. 


Figure  3-10. 

The  major  design  goals  include: 

•  ABT  shall  support  collection  of  sequence  codes  for  all  feeders  at  a  station  for  a  given  time 
period. 

•  ABT  shall  provide  the  capability  to  validate  that  a  product  uses  certain  component  parts  from 
each  of  the  stations  in  the  route  for  the  given  product. 

•  ABT  shall  support  operator  to  change  part  sequence  codes  in  a  feeder  or  slot  when 
replenishment  is  necessary.  In  addition,  it  will  support  off-line  feeder  setup. 

•  ABT  shall  provide  the  capability  to  “insert”  serialized  components  or  sub-assemblies  into 
higher  level  assemblies,  with  complete  traceability. 

•  ABT  shall  provide  the  capability  to  compute  component  consumption  for  each  station  and 
provide  this  data  to  an  external  material  management  system. 

•  ABT  shall  provide  the  capability  to  determine  what  high  level  products  contain  a  component 
part  vdth  a  particular  sequence  code  or  lower  level  assembly  serial  number. 
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•  ABT  shall  provide  a  complementary  set  of  reports  to  provide  the  as  built  component  part  list 
with  sequence  codes  or  serial  numbers  for  all  products. 

Figure  3-1 1  above  is  the  dataflow  diagram  which  shows  major  design  elements  for  this  sub-system. 


As  Built  Traceabilitv  (ABTl  Dataflow 


3.11  Alarm  Management  (AM)  Design  Description 

The  main  function  of  the  Alarm  Management  (AM)  Sub-System  is  to  provide  the  capability  to 
initiate,  track  and  log  events  for  all  notable  operator  and  application  events.  In  this  regard,  AM 
supports  the  configuration,  collection  and  reporting  of  all  events,  alarms  and  mail  messages  in  the 
system.  To  achieve  this  a  number  of  functional  elements  have  to  be  made  available.  These  are 
discussed  in  detail  in  the  RS  document. 

The  major  design  goals  include: 

•  AM  shall  support  the  configuration  of  events,  alarms,  and  mail  entities  for  the  Factory  Control 
System. 

•  AM  shall  support  the  capability  to  send  event  notices  to  any  station  on  the  route. 
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•  AM  shall  provide  the  capability  to  track  and  log  all  of  the  events,  alarms  or  mail  notifications 
generated  by  the  station  or  Users. 

•  AM  shall  provide  the  capability  to  bring  to  the  operator’s  attention  notable  events  that  have 
been  generated  by  applications,  or  other  system  components. 

•  AM  shall  provide  a  sets  of  reports  to  provide  the  history  of  alarms  for  a  particular  product  and  / 
or  user. 

Figure  3-12  is  the  dataflow  diagram  which  shows  major  design  elements  for  this  sub-system. 


Alarm  Management  (AM)  Dataflow 


Alarm  /  Event 
Configuration 
User  DM 
«RS-5.7.1» 

*  Provides  Maintenance  of 
all  Alarm  /  Event 
Management  tables, 
including  Mail. 


Automated  Station 
User  Operator 
«RS- 5.7.3  >> 

*  Advance  Changeover 
nofification  requests. 


Any  Station 
User  Operator 
«RS-5.7.3». 

*  Operator  Attention  for 
Alarm  Handling. 


Any  Supervisory  Station 
User  Supervisor 
«RS-5.7.3» 

*  Production  Report  Alarm. 

*  Email  Notification. 


Advance  Changeover 
Notification  Function 
«RS-6.14» 

’  Notifies  Downstream 
I  stations  of  New  and  Pending 
Changeovers. 


Operator  Attention 
Handling  Function 
«RS-5.7.2» 

*  Provides  Management  of  all 
I  Operator  Attention  Requests 
and  Responses. 


Production  Report 
Attention  Function 
«RS-5.7.2» 

•  Provides  Management  of  a  11 
Report  generated  Atte  ntion 
Requests  and  Responses. 


Active  Applicaiion 


Request  Function 
«RS-6.2.1» 

*  Provides  Management  of  all 
Attention  Requests  among 
applications  /  users. 

*  Currently  supported  for 
Defects  throu^RTFB. 


1 

, _ 

1 

Alarm  History  Report 
User  Supervisor 
«RS-5.7.2» 

*  Alarm  History  for  Station. 

*  Alann  History  for  User. 


Figure  3-12. 


Appendix  4  -  User  Based  Dataflow  with  Description 
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4.  User  Based  Dataflow  with  Description 

The  major  User  Based  Dataflows  are  separated  into  ten  sets  of  user  interactions  with  the  CIM 
System.  Where  as  the  sub-system  based  dataflows  provided  details  of  all  the  modules,  these 
dataflows  provide  the  flow  and  modules  to  be  used  by  the  “user”  to  achieve  the  specific 
functionality  desired  of  the  CIM  System. 

The  following  major  user  data  flows  are  discussed  in  the  following  sub-sections: 

•  Factory  System  Set  Up 

•  Product  Data  Set  Up 

•  Schedule  a  Product 

•  Create/Birth  of  the  Product 

•  Start  Product  Down  the  Line 

•  Product  Changeover  on  Line 

•  Component  Trace  based  on  Product/Serial  Number 

•  Component  Trace  based  on  Sequence  Code 

•  End  Item/Component  Consumption  Feedback 

•  Archiving/De-Archiving 

4.1  Factory  System  Setup 

Figure  4-1  provides  the  necessary  steps  and  the  sequences  that  a  typical  “user”  as  defined  in  each  of 
the  modules  will  take  to  configure  the  factory  system.  This  is  the  first  activity  to  be  done  before 
any  product  or  production  activity  is  started. 

4.2  Product  Data  Setup 

Figure  4-2  provides  the  necessary  steps  and  the  sequences  that  a  typical  “user”  as  defined  in  each  of 
the  modules  will  take  to  get  product  data  from  the  external  Product  Data  Management  (PDM)  and 
Material  Movement  System  (MMS)  and  work  with  the  CIM  System.  This  will  achieve  the  goal  of 
getting  design  and  planning  data  to  the  CIM  System  for  the  necessary  manufacturing  bill  of 
materials(MBOM)  and  machine  programs. 
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Product  Data  Set  Up 

a).  Product  Data  Preparation  (Design-to-P  rod  action  l/F  System  -  Machine 
Programming  System,  CIM  Preparation  System) 


PDM 

System 


MMS 

System 


Poputate 
Item  master 


E60M 

Item^Master 

Dooment 

Control 


Product  Configuratbn 
Maintenance 
User  Process  Eng., 
Doc.  Control 
«RS-6.1.4» 

*  Modify  E BOM  and 
generate  M  BOM 

•  Assigi  PL  Rev.  to 
MBOM. 

Validate  MBOM  against 
tern  nraster 


CAM  Uiifes 
*Validate  TIFagainst 
MBOM 


Mfg  Location 
Maintenance 
User  CIM 
«ON-1» 

*  Provide  Mfg  location 
(machine)  names. 

*  Provides  easy(wildcard) 
mehod  of  relating  Mfg 
locations  to  Operations. 


VaSdated  TF 


Vaiid^ed 

MBOM 


SbrPart/Ma  chine 
relattanship 


TIMMS 

System 


Feeder  /  Slot 
Maintenance 
User  Process  Eng. 
«RS-3.ai(» 

*  Maintain  the  Feeder  to 
Slot  Relationship 

*  Pro/ides  for  "Off-ine" 
set  up  of  Feeder  to  Part 

*  Provides  association  of 

Partto  Set  cn  Machine 
iwiBicxlicl _ 


1  ^ 

.  . 

Machine 

Pregrams 

Figure  4-2. 


In  addition  Figure  4-3,  the  second  data  flow  in  this  set,  provides  the  necessary  supporting  route  and 
product  setup  data  necessary  to  build  the  product  on  the  production  line. 


84 


b)  Product  Configuration  (Production  Change  Over  System  •  CIM  database  change  over  system, 
Operator  change  over  system) 


Create  /  Maintain  Route 
User:  Process  Engr 
«  RS-5.4.2» 

*  Create  New  route  from 
scratch  or  by  copying. 

*  Supports  drilldown  to 
route  details,  and 
alternate  routes. 


Build  Eff activity 
Maintenance 
Usen  Planner 
«RS^.1.4» 

*  Maintain  the  Buid 
Effectivity  based  on  date, 
count  or  serial  number. 
*Albws  Buid  Status  to 
be  Modified. 


Maintain  Changeover 
Configuration 
User:  Process  Engr 
«RS-3.2.3» 

*  Provides  active  feeder 
to  slot  to  part  relatbnship 
for  a  configuratbn  of  a 
product. 


Mfg  Instruction 
Maintenance 
User:  Process  Engr 
«RS-3.2^» 

*  Provides  work 
instructions,  part 
programs,  test  programs, 
rec^is,  GUI  for  a  route 
for  a  configuratbn  of  a 
product. 


Product  Con  fig  urat  ion 
Maintenance 
User:  Process  Eng., 
Doc.  Control 
«RS-6.1.4» 

*  Maintain  a  I  the 
appropriate  engineering 
and  Mfg  revisions  for 
product. 

Alows  management  of 
Product  Revisbn. 


Figure  4-3. 

Figure  4-4,  the  third  user  data  flow  in  this  set,  provides  the  necessary  supporting  route  and  data  set 
up  for  the  quality  model  of  the  product. 
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c)  Quality  Model  (Feedback  to  design) 


Verification  Effectiveness 

Create  /  M  aintain  Route 

Maintenance 

User:  Process  Engr 

User:  Quality  Eng. 

«  RS-5.4.2» 

«RS-5.3.1» 

«DN.10» 

«DN-11» 

•Create  routing  table 

•Specify  ver^ication 

with  PPM  and  verification 

effectiveness  by  process 

effectiveness  specified  to 

and  by  parts. 

processes. 

Compute  Quality  Model 
PPM  for  product 


Product  Configuratbn 


Product  Structure 
Maintenance 
User:  Planner 
«RS«3.1.3» 
«DN-13» 

*  Create  Mfg.  BOM  with 
\rendor  provided  PPM. 


Modify  PPM  as  needed 


Figure  4-4. 


4.3  Schedule  a  Product 

Figure  4-5  shown  below  provides  the  necessary  steps  and  the  sequences  that  the  planner  would 
need  to  take  to  schedule  the  product  for  production. 
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Schedule  A  Product  fPesion-to-Production 
VF  System  -  CIM  Preparation  System) 


Build  Effectivity 
Maintenance 
User:  Planner 
«RS-ai.4» 
*Maintiin  tieBuld 
Effectivity  based  cn  date, 
count  or  serial  nun ber. 
^Allows  Build  Status  to 
be  Modified. 


Day-1  Activity 


Production  Day  and 
after 


Product  Configuration 
Validation 
User  Plamer. 

«RS-&1.4» 

*  Provides  complete 
status  reporting  for 
product  buid 
ccnfiguafon 
♦Cycles  through  routes 
formfgrevistonand 
checjgvalicitv. 


reate  NewRepetitiw 
Schedule  /  Order 
User:  Planner. 
«RS^15» 
Provides  for  New 
Repeltive  SchediJe  or 
Order  Creation. 

♦  BuldsandVaidates 
the  Schedule /Order 
List 


MMS  Interlace  For  Item  Master 
User:  Planner?? 

♦Check  avail  abiity  of 
component  parts  for  product 
buad. 


Schedule  /  Order  Status 
User  Planner 
«RS-5.1.5» 

*  Complete  Status  on  Sc  hedule 
/  Orders 

*  P  rev  ides  summary  data  on  units 
started,  completed  and  h-process 


Function 
Usen  Planner?? 
«R&5.1.5>> 

*  Veriies  that  the  schedule  a 
Order  for  currert  product 
configuratbn  can  be  biit. 
♦Validates  Efectivity. 
♦Provides  Line  Side  Storage 
Acivai on  No! ce  to  M  MS. 


Schedule  /  Order 
Mailt  enance 
User:  Planner. 
«RS>^1.4» 

(♦  Provides  for 
M  airtenance  of  S  chedule 
or  Orders. 

'  May  be  provided  by 
I  Vendor. 


Schedulhg  Capacity  Report 
User:  Planner 
«RS'SL1.5» 

♦Prwides  summary  min,  max  and 
mean  ferougfeput  data  by  operation 
for  historical  product. 


MMS  UneSideStaage 
♦Activate  ine  side  storage 


Figure  4-5. 

4.4  Create/Birth  of  the  Product 

Figure  4-6  shown  below  provides  the  steps  taken  at  the  bar  code  label  station  of  the  line  where  the 
bar  code  labels  are  printed  and  applied  to  the  PWA  for  the  requested  schedule.  The  numbers  on  the 
arrows  show  the  sequence  the  controlling  Work  Station  will  take  to  achieve  this  purpose. 
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Create/Birth  Of  The  Product  fPesign-to- 
Production  l/F  System  -  CIM  Preparation  System) 


Figure  4-6. 
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4.5  Start  Production  Down  the  Line 

This  dataflow  shown  below  in  Figure  4-7  provides  the  steps  taken  at  the  first  production  station  of 
the  line  where  the  PWA  label  is  scanned  and  appropriate  validation  is  done  to  start  the  PWA  down 
the  manufacturing  line. 


Start  Product  Down  The  Line  (System  Architecture  - 
Work  Cell  Controller  Svsteml 


User:  Line  Operate  if 
Supeivisor 
«RS-6.1.0» 

«  OS-3.1» 

*  Birth  /  Create  New  PWA 


Figure  4-7. 
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4.6  Product  Changeover  on  the  Line 

This  dataflow  shown  below  in  Figure  4-8  provides  the  steps  taken  at  the  second  and  subsequent 
station  of  the  line  where  there  is  need  for  production  set  up  changes  to  build  a  different  product 
than  the  one  being  built  currently.  The  numbers  on  the  arrows  show  the  sequence  order  the 
controlling  Work  Station  will  take.  The  dataflow  shows  two  separate  sequences  -  one  for 
changeover  preparation  when  an  “advance”  notice  is  received  and  the  second  for  the  changeover. 

Product  Change  Over  On  Line  (Production  Change 
Over  System.  System  Architecture  -  Machine/Line  l/F 

System) 


Up  Stream  Stations 


Note:  1 , 2,  and  3  are  advance  notification  for  product  change  over 

Figure  4-8. 


90 


4.7  Component  Trace  based  on  Product/Seriai  Number 

This  dataflow  shown  below  in  Figure  4-9  provides  the  steps  taken  by  the  “users”  shown  below  to 
identify  the  necessary  reports  available  for  each  and  every  PWA  built  in  current  and  planned  CIM 
System.. 


Component  Trace  Based  On  Product/Serial  Number  (Production 
Performance  and  History  System  -  IBP  Traceability  System.  IBP  Produr.t 

Specific  Meeds) 

Users:  Quality,  Manufacturing,  CIM  Engineers 


Product  Build  Report 
User:  Process  Engr,  Operator 
«RS-6.5.2» 

*  Shows  ali  component  parts  down  to  the  lowest  items. 

*  Provides  sequence  code  and  serial  number  to  rail  ccxnponents. 


PWA  History  Report 
User:  Line  Superviosr 
«RS-3.3.5» 

*  W1 P  History  of  PWA 

*  Tine,  Operator  and  Buid 
Data 

*Test  Status 


*  Data  From  Existing 
CIM  System 
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4.8  Component  Trace  based  on  Sequence  Code 

Figure  4-10  below  shows  the  steps  taken  by  the  “users”  shown  below  to  identify  the  necessary 
reports  available  for  each  and  every  Sequence  Code  that  may  be  a  cause  for  concern  in  the  system. 
Note  the  capability  to  also  purge  the  active  components  and  PWA  from  the  production  line. 


Component  Trace  Based  On  Sequence  Code  (Production 
Performance  and  Hi  story  System  -  IBP  Traceability  System. ■.IB.& 

Product  Specific  Needs) 

User:  Quality,  Manufacturing,  CIM  Engineers 

.  n  n . 


u 

Component  With 
Sequence  Code 

1 


Sequence  Code  Report 
User:  OM,  Process  Engr 
«RS-5.6.2» 

*  Provides  all  PWA  that  contain  particular  Sequence  Code 

*  Provides  current  status  aixJ  Operatbn  of  PWA 

*  Archived  a ixl  Active  Data  is  used. 

*  Active  Feeder  Lot  Codes. 


Put  PWA(s)onhold 
if  on  line 


Figure  4-10. 


4.9  End  Item/Component  Consumption  Feedback 
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Figure  4-11  shows  the  steps  taken  by  the  “users”  and  the  system  to  identify  and  report  the 
component  consumption  and  the  end  item  PWA  inventory.  This  capability  is  to  be  provided  on  a 
timely  basis,  and  depending  on  the  performance  of  the  system  may  be  “real-time”. 

End  Item  /  Component  Consumption  Feedback  (Desian-to- 
Production  l/F  System  -  MMS  l/F  System) 


Pack  /  Ship  Station 
Usen  Operator 
«  RS-&1.7» 

«os-ai» 

*  WlP-INFunctton 
^WIP-OUT  Function 
"  Complete  WIP  Function 
^  Archive  WIP  Function 


Any  Station 
User:  Operator 


Complete  WIP  Function 
«RS-ai.7» 

*  Update  Appropriate  WP 
and  Routing  Tables 

*  Update  Repetitive 

Schedule  /  Order  Complete. 

*  Send  Uni  Complete 

Notice  to  MMS 

\, 

i 

MMS  Interface  for 
Component  Consumption 
«RS-&6.2» 

*  Updates  ^^S  Database 
for  Component 

Consimption 

*  Periodica  By  computes 
consumption,  based  on 
unit  complete  a  time 

X 

X: . 

I- ‘ 

Unplanned  Component 
Consuption  (Paitof  MMS) 
User:  Planner 


Figure  4-11. 
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4.10  Archiving  /  De-Archiving 

This  dataflow  shown  below  in  Figure  4-12  provides  the  steps  taken  by  the  database  administrator 
and  the  system  to  provide  archiving  and  supporting  de-archiving  capability. 


Archiving  /  De-Archiving 
User:  DBA 


Unit  Complete  From 
Last  Station  Of  Route 


Archive 
WIP  Function 
«  RS-???» 

•  Rolls  up  WIP  Data  into  an 
Archive  log  and  updates 
appropriate  Archive  and 
Dearchive  Tables. 

*  Delete  from  Line  Server. 


(Line  Unit  Complete  Function) 


Archive  Factory 
Function 
«  RS-7.2» 

«  DN-8» 

*  Rolls  up  Factory  Config 
Data  such  as  users, 
operations,  bcationsv  etc. 
into  an  Archive  bg  and 
updates  Archive  and 
Dearchive  Tables. 


\_ 


Roll  Up  Into  Rat  RIes 
Wl P/Trace  Data  From 
Factory  &  Cell 


FCS  Database 
WIR Trace  Tables 


Figure  4-12. 
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Appendix  5  -  Design  Notes  (DN) 


1 .  Each  of  the  physical  locations  where  work  is  to  be  performed  is  considered  a  “station”  or 
Mfg.  Location.  Where  ever  a  PWA  is  inspected,  tested,  added  to  or  changed,  that  functional 
entity  is  an  “operation”.  Typically  a  station  performs  one  operation.  For  reasons  of 
production  there  may  be  many  “stations”  that  perform  the  same  “operation”.  Conversely, 
for  activities  that  are  sporadic,  or  do  not  require  a  significance  amovmt  of  work,  there  may  be 
many  “operations”  performed  at  a  single  “station”.  In  addition.  Operation  Type  is  used  to 
provide  some  level  of  authorization.  The  same  class  of  operation  belongs  to  the  same 
Operation  Type.  Typically  a  user  or  user  group  is  defined  to  be  capable  of  performing  an 
Operation  Type.  The  relationship  among  them  is  graphically  represented  as  follows: 


2.  To  support  the  capability  and  flexibility  of  having  user  authorization  and  shift  data 

collected,  the  design  of  the  data  model  will  relate  users  to  user  groups.  The  system  is  capable 
of  providing  a  generic  user  belonging  to  a  generic  group,  all  of  who  can  do  every  operation 
type,  and  belong  a  single  shift.  This  is  the  simplest  way  to  minimize  user  protection.  On 
the  “secure”  end,  all  users  can  have  their  own  passwords  and  be  capable  of  performing  only 
certain  operation  types  on  a  certain  shift.  This  relationship  is  show  below: 


3 .  The  relationship  between  the  various  storage  devices  and  machine  locations  is  given  in  the 
diagram  below.  For  standardization,  the  following  is  to  be  the  terminology  to  be  used. 
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•  Slot  (aliases  are  Bin,  Box)  --  is  the  physical  location  on  a  station  (Mfg.  Location) 
where  parts  are  inserted.  In  the  case  of  reeled  parts,  reels  are  placed  on  the  feeder 
and  the  feeder  assembly  is  placed  in  the  slot. 

•  Feeder  —  is  the  physical  device  on  which  reeled  parts  are  placed.  Feeder  may  have 
his  or  her  own  identification.  They  are  not  related  to  any  particular  machine. 

•  Line  Side  Storage  -are  the  locations  on  the  plant  floor  next  to  production  lines  where 
temporary  storage  is  made  of  parts  of  short-term  consumption. 

•  Part  —  is  the  component  part  that  is  related  to  a  slot  on  a  particular  machine  for  a 
specific  product.  It  may  temporarily  be  put  on  a  feeder  assembly. 


In  support  of  this  design,  the  off-line  feeder  part  setup  shall  be  provided  so  that  Feeders 
may  be  setup  “off-line”  with  feeder  to  component  part/sequence  code  data.  Then  when  the 
feeder  is  used  for  replenishment  or  changeover,  the  operator  will  only  need  to  associate 
feeder  to  machine  slot.  This  will  result  in  the  system  than  identifying  slot  to  component 
part  for  Product,  with  the  associated  sequence  code. 

4.  The  Repetitive  Schedule  is  defined  by  the  plaimer  and  is  capable  of  providing  build  request 
of  quantities  for  shifts,  days,  or  weeks.  Each  of  the  build  requests  shall  have  a  reference 
build  number  consistent  with  the  way  an  order  is  generated  and  built.  The  Start  of  Build 
Validation  is  to  provide  for  daily  validation  of  orders  or  of  the  repetitive  schedule.  If  the 
order/schedule  is  “old”,  then  only  MMS  line  side  storage  activation  shall  be  done  else 
validation  and  activation  is  to  be  done. 

5.  The  MMS  Interface  is  to  support  the  activation  of  which  line  side  storage  locations  are  to  be 
monitored.  The  capability  to  be  provided  by  the  CIM  System  is  what  bins  are  to  be 
activated  based  on  the  product  being  built. 

6.  The  Planned  Setup  Report  is  provided  for  the  supervisors  or  operators  to  look  at  the  setup 
for  each  and  every  station  on  the  line  for  a  particular  product.  This  data  is  originally 
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provided  by  the  TIMMS/2  system,  and  utilities  are  provided  to  put  this  data  into  the  CIM 
System  database  for  reporting  purposes. 

7.  The  master  control  of  the  next  valid  serial  number  is  to  be  maintained  in  the  CIM  database. 
For  maintainability  of  this  data,  supervisory  control  should  be  made  available  and  the 
necessary  forms  provided. 

8.  Archiving  and  Dearchiving  of  data  is  critical  to  a  system  where  the  production  volume  is 
high.  To  this  end  the  strategy  for  the  archiving  and  dearchiving  is  a  follows: 

•  Deletion  —  All  WIP  data  from  the  Line  servers  shall  be  deleted  when  the  unit  is 
“completed”.  Data  is  to  remain  in  the  FCS  DB  until  it  is  archived.  Also  all  product, 
component  trace,  and  event  data  is  to  be  deleted  from  the  Line  Server  “periodically”. 
This  will  be  done  by  the  Database  Administrator  (DBA).  When  any  significant 
changes  are  made  to  the  production  line,  the  entire  database  for  the  line  server  is  to  be 
deleted  and  only  the  relevant  tables  for  the  new  products  populated  by  the  DBA. 

•  Archiving  --  All  WIP  and  Trace  data  from  the  FCS  server  shall  be  rolled  up  into  flat 
files  and  compressed.  This  activity  is  to  be  done  when  the  unit  has  been 
“completed”  for  over  1  year.  In  addition,  all  table  data  that  is  over  a  year  old  is  to  be 
archived  using  Oracle  tools  then  deleted  from  the  tables.  This  activity  is  to  be  done 
on  a  monthly  basis  with  a  rolling  1-year  window.  This  will  be  done  by  the  Database 
Administrator  (DBA). 

•  Dearchiving  --  Depending  on  the  need  for  dearchiving  either  the  archived  tables  or  the 
flat  file  WIP  and  Trace  data  is  brought  back  into  “new”  tables.  Tools  and  utilities  for 
the  normal  table  dearchiving  will  be  provided  by  the  Oracle  RDBMS.  For  flat  files, 
PL/SQL  and  SQL*Forms  utilities  will  be  provided  to  allow  this  data  to  be  quickly 
scanned  for  items  such  as  “sequence  code  for  components”,  start  or  complete  dates, 
etc. 

9.  In  support  of  the  Quality  Model  integration  with  the  CIM  System’s  bill  of  material  and 
configuration  management  applications,  clarifications  are  as  follows: 

•  All  the  component  parts  in  the  product  must  have  their  part  packages  defined.  For 
sake  of  simplicity,  only  the  high  PPM  component  parts  should  be  defined.  As  the 
product  gets  closer  to  Production,  all  other  parts  can  be  added. 

•  For  each  component  part/package  type,  the  MFGLOCATION  that  the  part  and  the 
associated  slot  it  will  be  used  in.  For  sake  of  simplicity,  the  slot  does  not  have  to  be 
exact.  They  can  be  off  until  the  actual  part  programs  are  done.  Also  the 
MFGLOCATION  can  be  some  default  “Machine”  if  so  desired.  The  selection  of  the 
actual  machine  can  be  done  after  the  part  program  is  generated. 

•  The  relationship  between  the  various  storage  devices  and  machine  locations  is  given 
in  the  diagram  below.  For  standardization,  the  following  is  to  be  the  terminology  to 
be  used. 
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•  Part-package  -  is  the  package  type  that  can  be  place  by  a  station  (Mfg.  Location) 
where  parts  are  inserted.  There  is  a  many  to  many  relationship  between 
MFG_LOCATION  and  PART_PACKAGE. 


1 0.  User  will  then  define  the  route  the  product  will  follow  as  it  is  being  produced  on  the 
manufacturing  line.  This  will  entail  defining  for  the  CIM  system  the  following: 

•  All  the  OPERATIONS  and  /or  MFGLOCATION’s.  For  sake  of  simplicity,  only 
the  high  Process  PPM  drivers  and  Verification  processes  should  be  defined.  As  the 
product  gets  closer  to  Production,  all  other  locations  can  be  added. 

1 1 .  To  support  the  capability  and  flexibility  of  having  generalized  to  very  specific  PPM  levels 
for  the  product,  the  following  order  of  precedence  for  “PLANNED”  or  “ACTUAL”  PPM 
levels  each  station,  operation  or  operation  type  on  the  route  will  be  followed: 

•  If  MFGLOCATION  is  specified,  the  planned  or  actual  PPM  will  be  used  based  on 
the  part_package  type.,  if  no  PPM  is  available,  then  it  will  go  the  to  next  higher 
generalized  level  of  “operation” 

•  If  OPERATION  is  specified  or  no  PPMs  are  available  from  MFGLOCATION, 
planned  or  actual  Operation  PPMs  are  to  be  used.  Note  that  this  is  independent  of 
partjpackage  type,  however  if  not  available  then  it  will  go  the  to  next  higher 
generalized  level  of  “operation  type” 

•  If  OPERATION  PPMs  are  not  available  OPERATION  TYPE  planned  or  actual 
PPMs  are  to  be  used,  however  if  not  available  an  error  will  be  generated  for  the 
model. 

12.  The  current  CIM  Data  Model  uses  a  simple  Yield  concept.  To  support  the  Quality  model 
the  PPM  concept  is  being  added  and  it  shall  be  made  comprehensive  to  support  the 
following: 

•  Every  Physical  or  logical  entity  in  the  plant  that  affects  the  quality  of  the  product 
will  have  a  PPM  ID.  For  the  basis  of  the  Quality  Model  there  will  be  three  (3)  types 
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of  PPMs.  Process  PPM,  Part  PPM  and  Verification  Effectiveness  PPM.  The  data 
model  will  allow  further  expansion  to  include  Design  PPMs,  etc. 

•  Process  PPMs  are  for  process  locations  such  as  MFGLOCATION,  OPERATION, 
OPERATION_TYPE.  This  PPM  ID  will  point  to  two  PPM  values  -  one  “planned” 
and  the  other  “actual”.  “Planned”  values  are  to  be  entered  by  the  Quality  or  Planning 
personnel.  “Actual”  will  need  to  be  computed  on  a  periodic  basis  from  feedback 
from  the  Real-Time  Defects  Databases  and  entered  by  the  Process  personnel. 

•  Component  PPMs  are  for  component  parts  and  products.  Similar  to  process  PPM, 
the  PPM  ID  will  point  to  two  PPM  values  -  one  “planned”  and  the  other  “actual”. 
“Planned”  values  are  to  be  entered  by  the  Quality  or  Planning  personnel  based  on 
some  planning  value  “Actual”  will  that  which  is  provided  by  the  part  vendor  and 
entered  by  the  Process  personnel.  In  addition,  if  neither  is  available  the  values  for  the 
PART_PACKAGE  will  be  used.  This  will  point  to  the  same  PPM  Type. 

•  Verification  Effectiveness  PPMs  are  for  all  quality  assurance  locations  such  as  In- 
Circuit  Test,  Visual  Inspection,  etc.  This  PPM  ID  will  point  to  two  PPM 
effectiveness  values  -  one  “process”  and  the  other  “component”.  “Process”  values 
are  how  effective  the  location  is  in  performing  the  verification  on  the  process  defects. 
“Component”  values  are  how  effective  the  location  is  at  performing  the  verification 
on  the  component  flaws.  Note  that  this  verification  is  to  be  comprehensive  and  shall 
take  into  account  that  this  verification  effectiveness  may  be  applicable  to  only  a 
subset  of  components  and  processes.  Supporting  Data  Structures  shall  be  needed  to 
support  user  interaction  to  specify  this  and  keep  in  the  database  for  future  use  and 
traceability. 

13.  Finally  the  User  can  interact  with  the  QM  and  get  output  in  the  form  of  a  screen  report  that 
will  look  like  spreadsheet  report.  Note  the  following: 

•  The  user  will  “adjust”  PPM  levels  by  identifying  new  PPM  Values  or  changing 
existing  values  and  seeing  the  impact  to  the  bottom  line  PPM. 

•  The  user  may  alternatively  modify  the  route;  the  bill  of  material  associated  to  the 
route  and  re-run  the  model  parameters  to  get  a  new  value. 

•  Note  that  the  order  of  Operations  in  this  model  is  important,  as  the  model  is 
sensitive  to  what  order  of  the  operations. 

•  A  spreadsheet  like  view  will  need  to  be  provided  to  the  user  to  ascertain  which 
processes  and  parts  are  being  “verified”  by  the  processes  that  have  verification 
effectiveness.  The  level  of  effective  is  the  same  for  all  type  is  “checked”,  and  zero  if 
“not  checked”. 
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